The Google Summer of Code program is over now and this project's outcome will be merged into the main SOS trunk. Please refer to the documentation for details.
The 52°North SOS implements only a subset of the O&M data format. To support SOS users that have constraints by either technical oder domain specifics, it would be useful, if users could just implement a simple encoding (for example to support their own CSV or JSON data format) and upload a compiled jar file to the SOS with a browser-based user interface. Then a client selects the newly available response format to retrieve the data in a new format. As an extension it would be very useful to researchers and data maintainers in the hydrological and meteorological domain to have the SOS server deliver WaterML2.0 Standards Working Group">WaterML2.0 encoded time-series. Based on the SOS adminstrator project, the desired encodings could be prepared as .jar-files and added via a web frontend.
Find me:
Shall trunk updates and/or SOSAdministrator updates be merged into Exchangeables Encodings branch regularly- yes, latest changes to 3.5 -- AlexanderKmoch - 2012-07-02
describe data flow within SOS server, Request - Listener - DAO - Encoding - Response - "big picture" (see BlogEntry and WeeklyReport) -- AlexanderKmoch - 2012-06-04
List supported ResponseFormat varieties (encoings) in GetCapabilities response, respect om:Observation and om:Measurement for e.g. CSV, how data format -- AlexanderKmoch - 2012-06-04
how does an observation quality representation look like? example?
what about ENCODING <-> OFFERING / phenomen? e.g. apply WaterML output on, let's say geologic or atmospheric sampling doens't make sense? Just throw exception from encoder?