This is the first blog post for the Google Summer of Code 2013 project being organized by 52°North and me with the goal of adding support for seismic data in the existing applications Sensor Observation Service (SOS) and Sensor Web (SWE). These applications currently function in unison to provide a user with sensor data; to display both the sensor location on a map, as well as the corresponding graphical information the user asks for. The data formats that are supported right now are based on climate and hydrology sensing and the applications have so far existed for the purpose of analyzing this sort of observation information. This project’s outcome more >
The final sprint towards the end of the Google Summer of Code (GSoC) is over now. After fixing bugs, working on documentation and actually producing time-series in different formats, the “Exchangeable Encodings for SOS” project met most of its ambitious goals – and it is demonstrated on the 52°North Google summer of Code Demo Server. Users and developers documenation on the encoding mechanism has also found a place in the 52°North wiki.
We have integrated a plugin mechanism into an SOS server (source code branch), which is based on the main 52°North SOS development line (source code trunk). As a proof of the concept, two basic plugins are provided:
- Plain CSV (comma separated values) response format, which tries to stick to recommended NOAA IOOS Data Integration Framework CSV output,
- WaterML 2.0 (OGC WaterML 2.0 and Hydro DWG). I acquired a recent version of the WaterML 2.0 encoding profile, which is already adopted as a (candidate) standard. The schemas are not yet officially published and rumours have it that there might be last minute changes. The change request contains an extension regarding empty time-series responses which should not interfere with the existing implementation.
In the world of many diverse forms of observation types for natural phenomena, the two plugins demonstrated both rely on point-based measurement data.
Where to go from here?more >
The time is flying by and soon we reach midway of the Google Summer of Code (GSoC) with 52°North. It is the typical time in between – I already managed to meet the first milestones, but there is no proper product yet. Catching up with the changes from the SOS main development branch is a constant challenge, but the infrastructural changes within the “Exchangeable Encodings for SOS” project are slowly but continuously leading towards a robust and standardized, yet limited, encoding plugin API (application programming interface).
The main use case is the request for observations (GetObservation request) that could be delivered in CSV (comma separated values) format for legacy applications, WaterML2.0, an upcoming OGC (Open Geospatial Consortium) data transfer standard for the hydrological domain, possibly netCDF (Network Common Data Form), also an OGC standard for meteorological applications, and in O&M (Observations & Measurements) for the generic use within sensor networks and spatial data infrastructures.
An open question is whether there is a need to also encode sensor and feature information in different format (affecting DescribeSensor and GetFeatureOfInterest requests). And which other encoding schemes would be interesting? Please add your ideas in the comments! We are starting to document the preliminary API on the project’s wiki site:
[Starting today, our Google Summer of Code students will present their projects. Alexander Kmoch is first. Enjoy!]
As one of the 52°North Google Summer of Code projects, “Exchangeable Encodings for the 52°North Sensor Observation Service (SOS)” aims to implement a customisable result set encoding mechanism. The users would then be able to add their own compiled libraries (like plugins), which contain all the necessary code to provide the requested data in different formats, such as CSV or GeoJSON, to the SOS. When that mechanism works, we can easily add more encodings, e.g. the planned WaterML2.0 – but for now, where to start?