Exchangeable Encodings for SOS
Back to GSoC2012 Projects page.
Documentation Encoding Plugin Development
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.
Overview
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:
SVN URL: https://svn.52north.org/svn/swe/main/SOS/Service/branches/gsoc-exchangeable-encodings/
Major work packages
- Analyse SOS internal data model and architecture and the request / response and translation / encoding routines
- Deriving and implementing necessary changes to create flexible mapping / output encoding
- Implementing / customising existing coding / decoding and request/response classes (GetXXXListener)
- Customise mapping for default schema to custom (like WaterML2.0)
- Customise acquisition of encoding via an archive (or similar)
- Add at least one other simple (csv / GeoJSON) mapping
- Testing and documentation (try to keep Unit-testing and code documentation up-to-date while developing!)
Weekly Reports
Discussion and Ideas
(Please add signature.)
- 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?
Further suggested encoding schemes