[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?

The internal architecture of the 52°North SOS server is generally well structured. Based on the user request, the respective Listener will get the data from the data backend and send it to the corresponding Encoder.  The response document, very likely a collection of observations, is then returned to the user in the requested encoding, also referred to as the response format. The typical application flow of such a request is depicted in the comic strip below. Available response formats can be queried from SOS server and are listed in the capabilities document. To date the two integrated encoders return XML documents based on the OGC© O&M schema and the OGC© SOS versions.

There are different entry points to dynamically add more response encodings. Based on the internal software architecture, they could be implemented as additional full-fledged SOS server modules or as lightweight response format libraries that could be loaded at runtime and registered within the SOS internal “configuration manager”, the SosConfigurator instance. But the following constraints must be taken into consideration:

• The SOS protocol versions 1.0 and 2.0 must be honoured
• responseFormat O&M 2.0 ships as standard
• Listener and Encoder are coupled through the SOS protocol version, but the response encoding needs to be decoupled and dynamically selectable
• Other formats / encoders need to be “dynamically” registered in the SosConfigurator and to be identified and allocated based on the requested responseFormat value from the user request

One of the challenges is the generation of a non-XML-response in this XML dominated workflow. Since the SOS internal response object is merely a “string datatype”, a simple encoder would need to implement the SOS internal response model for the return value and should accept the SOS internal data collection representation delivered from the data backend. Here we can put the lever to enhance the versatility of the 52°North SOS server.