Last Friday, a new version of the SOS (Sensor Observation Service) Importer was released. This is a tool for importing observations from CSV (Character Separated Values) files into a SOS instance using an eight step wizard for guiding a user through the often cumbersome process of data transformation.
Exchangeable Encodings Getting in Shape
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:
Dynamic Output Formats for the Sensor Observation Service
[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?
OGC agrees on approving SOS 2.0 as a new standard!
We, the editorial team of the SOS 2.0 (Christoph Stasch, Johannes Echterhoff, and myself), are very happy to announce that the members of the OGC Technical Committee have finalized their voting on the SOS 2.0 specification, and formally agreed on approving the SOS 2.0 as an OGC standard!