Google Summer of Code Project Ideas 2014

Main Page: GSoC2014

The is the ideas page for the Google Summer of Code 2014. If you are an interested student please don't hesitate to contact mentors directly or discuss your own ideas on the mailing lists.

To add your idea, please use the project template at the end of the page or add a minimalistic sentence in the "coarse ideas" list - but add your signature in any case. Thanks!

Ready Ideas

Sensor Description Metadata Editor

Explanation: The 52°North SOS implementation is constantly moving to become more user friendly software. The upcoming release therefore includes a powerful administrative user interface, which includes the possibility to edit the server metadata. However, the editing of sensor description documents is still limited to a simple text form. This is partly due to the complexities of the default sensor description format, SensorML, but we think sensor metadata editing should be user friendly and simple despite of complexities of the underlying model. Therefore this project will develop a user friendly SensorML metadata editor that can be integrated and work with the 52°North SOS. The editor will be based on smartEditor. Particular challenging tasks would be template support and hierachical descriptions (using SensorML 2.0).

A student should have experience in object oriented software developed, preferably Java. Experiences with agile methods (Scrum), XML and XSLT are a plus.

Expected results
  • A smartEditor adapter for SOS which allows to load and save sensor descriptions form/to a SOS 2.0 using the operations DescribeSensor and UpdateSensor.
  • A preconfigured UI with all elements from the discovery profile supporting SensorML 1.0.1, including validation of the sensor description against the discovery profile and user friendly display of errors (could use the OpenSensorSearch validation service).
  • Live display of the GEO label for the currently edited metadata (extension of smartEditor independent from SensorML).
  • Experiments with full editing for SensorML (all possible elements based on the schema) resulting in a recommendation of a resonable level of detail for sensor description forms.
Optional results: Support for SOS 1.0.0, support for SensorML 2.0, a demonstrator integrating smartEditor into the SOS's admin interface, support for the internal API of the 52°North SOS to distinguish updates and edits, see this bug report.

Community Code and License: Sensor Web and/or Metadata Management, Apache 2.0

Mentors: Daniel Nüst (, Kristian Senkler ?

WPS 2.0 Implementation

Explanation: The Open Geospatial Consortium (OGC) has established a standards working group (SWG) to work on the version 2.0 Web Processing Service (WPS) specification. This has been going on for a while, but in the last months there has been some good progress. As some points are still open for discussion, and because OGC standards have been critized in the past years that they are "hard/impossible to implement" or that they do not cover realistic scenarios, we want a student to help to improve the standard that is developed by providing an implementation of the latest available public draft of the specification based on the current 52°North WPS 1.0 codebase, especially the "WPS-G" branch by Spacebel. With the experience from the implementation and demonstrations to be developed by the student, the SWG can get valuable inputs for shaping the next WPS specification.

If the student makes good progress, the implementation of CITE tests would be a possible extension of the work. In any case, the student will get to know a stable and well known web service implementation and how standards are made in an international organisation.

The potential student should have experience in web service implementation with Java and good communication skills. Agile software development experience and the ability to develop quick prototypes for usecases from the geospatial domain.

Expected results: A WPS 2.0 implementation (based on the public RFC version) based on the 52°North Processing Server codebase. This work could act as a base for a potential reference implementation of the WPS 2.0 specification.

Community and Code License: Geoprocessing, GPL 2.0

Mentors: Benjamin Pross (, Matthias Müller (

Rock the WPS

Explanation: The WPS is a mature software project. However there is of course always room for improvements. In this project you will debug, test, hack the WPS code base and/or documentation to make it an even better project.
There are some known issues and we also have a couple of new features that we'd love to see implemented.

The potential student should have experience in web service implementation with Java and good communication skills. Students should have an interest in improving an existing software and/or documentation.

Expected results: An improved WPS implementation possibly resulting in a new release.

Community and Code License: Geoprocessing, GPL 2.0

Mentors: Benjamin Pross (

Sensor Data Access for Rasdaman

Explanation: Rasdaman is a domain-independent array DBMS, and its petascope component provides a variety of standardised interfaces (such as OGC WCS(-T) and WCPS) to insert and retrieve geospatial data. This project should connect Rasdaman as a data storage backend to the 52°North Sensor Observation Service (SOS) implementation by adding Rasdaman as a data source in the 52°North SOS. This could be done at different levels: using SQL/Hibernate, a plain Java implementation (based on the Java API), or by implementing a generic JDBC driver. These drivers specify common interfaces for accessing relational databases, and many applications have plugins for connecting to databases via JDBC/ODBC drivers - so this would be a great contribution to the rasdaman community, too. At the beginning of the project a prospective student should test and evaluate these possibilities.

Further work would then include and implementation of the SOS-T interface for data insertion. The implementation shall be tested with a large climatology database such as HadCRUT, GHCN or ECA&D. This project is challenging but great at the same time because you get two know two Open Source communities within just one summer!

Some further reading: Expected results: 52°North SOS Rasdaman "data access objects" (internal data source represenation of SOS), Rasdaman Hibernate mappings for 52°North SOS, integration of the 52°North SOS into petascope (user guide, testing, and documentation), users can query data from rasdaman using the SOS interface (tested with the Sensor Web client and sos4R).

Optionally, the configuration of Rasdaman as a datasource could be integrated into the configuration wizard.

Community and Code License: Geoprocessing, GPL 2.0

Mentors: Daniel Nüst (, Carsten Hollman (, Dimitar Misev (

Access Control User Interface for SOS Servers

Explanation: The OGC Sensor Observation Service specification allows the interoperable provision of sensor data through a standardised interface. However, this interface does not include a mechanism for access control (i.e. a way to determine which user is allowed to download which data sets). To close this gap, the 52°North Web Security Service exists ( This service was not specifically developed for SWE services. Instead the focus of this service is on typical mainstream OGC services such as WMS, Catalog or WFS. While prototypical support for the SOS 1.0 standard exists the current 2.0 specification is not yet supported. Within this project, this gap shall be closed by adding support for the SOS 2.0 standard and adding an easy to use user interface for editing access rules to the SOS admin backend.

Optionally, the 52°North Sensor Web Client ( should be enhanced to allow the usage of SOS servers protected through access control mechanisms.

A student should have experience in object oriented software development, preferably in Java, and experience with web APIs.

Expected results: Software module (servlet) providing a so called interceptor for the SOS standard (version 2.0).

Community and Code License: Sensor Web, Apache 2.0/GPL 2.0

Mentors: Simon Jirka (, Carsten Hollmann (

enviroCar App UX Design

Explanation: Redesign and testing of the enviroCar app user interface. There is scope for designing and developing innovative visualizations of real-time data and extending to other platforms. Requires in-depth knowledge of UX design principles and at least one mobile operating system (Android, iOS, or Windows Phone). Student should have an interest in localization and providing a seamless user experience across languages, regions, and units of measure.

Expected results: New app UI for an operating system of the student’s choice.

Community and Code License: Sensor Web, Apache 2.0 License

Mentor: Carson Farmer (, Carsten Keßler (

enviroCar Linked Data

Explanation: Improve the way enviroCar data is served as Linked Data. Possible tasks are improvement of interlinking with other data sources, developing a SPARQL endpoint for e nviroCar, and reviewing and applying existing semantic sensor web ontologies to the data. The student may also evaluate/ensure compliance with the GeoJSON specification and the application of wrappers that expose the data as standardized geo web services. Student expertise should include semantic web technologies and relevant frameworks such as Jena.

Expected results: Compliant and/or innovative ways to access the enviroCar data.

Community and Code License: Semantics, Sensor Web, Apache 2.0 License

Mentor: Carsten Keßler (, Carson Farmer (

enviroCar Data Analytics

Explanation: Student will explore innovative ways of interacting with enviroCar trajectory data for environmental monitoring and efficiency assessment. Student will take advantage of existing (or future) enviroCar APIs to develop real-time monitoring workflows and batch analyses to generate information products for decision making. Student expertise should include a scripting language such as R or Python, as well as experience interacting with web APIs.

Expected results: Deployable workflow for analysis of enviroCar data.

Community and Code License: Sensor Web, Geostatistics, Geoprocessing; Apache 2.0 License

Mentor: Carson Farmer (, Carsten Keßler (

Statistics for OGC Web services

Explanation: Maintainers of 52°North SOS deployment currently do not know what the "most commen" requested procedures are and when people are requesting data for which area and time frame. Are users interested in the last week mostly, or do they request historical data as well? How large is the average response document and which sensor stations get rarely any queries?

To answer these questions, this GSoC project will develop an SOS plugin to capture "usage statistics". Keeping privacy in mind, information about the users (e.g. coarse location) is collected and stored in a manner that does not slow down the regular request handling. Information that cannot be captured by "regular" HTTP statistics (e.g. procedures, time period, observed properties) are of highest interest, "regular" statistics such as response time could be captured as well.

This project requires students to have experience with the full database modeling and user interfaces as well as Java, but is adaptable to different programming skills.

Expected results: SOS extension that collects service-aware user statistics based on a data storage mechanism (e.g. a web service) that can be extended to other OGC web services (e.g. SES, WPS), user statistics are configurable and can be displayed in the SOS admin backend.

Community and Code License: Sensor Web community, Apache 2.0

Mentor: Simon Jirka (, NN

Cloud images - testing and workflows

Explanation: The currently "large" web service software projects - i.e. SOS, WPS, SES, SOS clients, smartEditor, enviroCar server - have successfully been tested in cloud deployments. For easier testing and deployment by community members and new users, it would be very helpful if ready-to-deploy configurations and or images can be provided for download and be kept up to date with the latest release versions. This project starts with an investigation of existing cloud services (e.g. Amazon EC2, Microsoft Azure, Google Cloud Platform, ...) and matches their features to requirements/dependencies of 52°North web services. Afterwards the students must manually create and test individual and combined deployment of software projects. Eventually she must design and implement an (half-)automated workflow to create cloud images directly from source code repositories.

This project requires programming experience in a common scripting language (Python, bash). But most important are good communication skills (esp. good English writing skills) and thorough work style, and experience with different operating systems (Linux, Windows) as well as understanding technical documentation.

Expected results: Images for selected cloud infrastructures are generated on a regular basis for sensor web applications (SOS, SES, clients, Timeseries API) and processing services (WPS including R and GRASS processing backends), extensive user documentation allows beginners to quickly deploy 52°North services in a cloud of their choice.

Licenses: Code: Apache 2.0, Documentation: CC-BY.

Mentor: NN (52N staff), Eike?

Mobile sensor web client apps for all platforms and new client features

Explanation: In the sensor web community we're currently developing a "mobile sensor web client" (source code, demo), a plain Javascript/HTML5 application to visualise time series data coming from the Timeseries API. Based on PhoneGap/Apache Cordova, the student in this project will (a) develop and thoroughly test the application on as many mobile platforms as possible and then (b) participate in the agile development process for the remainder of the project.

For part (a), the student will compile documentation on how to publish the apps in the different markets/stores for all the platforms, create marketing material (texts, screenshots) for the app and eventually publish the app in all of the stores. Ideally, the publication process will be automized as much as possible (using scripts, build systems such as Maven, the PhoneGap build service, ...). This part also includes detailed testing of the appliations and communication with users of the app to collect and fix bugs.

In part (b) the student will join the agile development of 52°North developers and in close contact with customers work on new features for the mobile sensor web client. Examples for features are adding an interactive overview graphic for exploring time series and adding flexible support for i18n. The student is expected to test the mobile client and submit his/her own ideas for new features in the application. Currently open issues should be taken into account.

Required skills: Javascript, app design, experiences with Apache Cordova/PhoneGap, good organisational skills. ALERT! You don't require access to mobile devices for all operating systems.

Expected results: Sensor web client as apps in markets/stores/marketplaces for Firefox OS, Microsoft Metro, Windows 8, Android, and iOS, well-documented (half-) automatic procedure for publishing the apps, active participation in a feature development team.

Community and Code License: Sensor Web community, Apache 2.0

Mentor: Jan Schulte (, Daniel Nüst (

Timeseries API for the Internet/Web of Things

Explanation: The web of things is a big deal. The Timeseries API has proven very useful for client development. This project will combine these two developments by implementing datasources for the Timeseries API that connect to popular Web of Things/Web of Data/Internet of Things platforms such as Xively, Nimbits, ThingSpeak or

This project requires good Java development skills and experience with public APIs and authentication.

Expected results: Live data can be accessed via the Timeseries API from a selection of IoT platforms and displayed in the mobile sensor web client.

Community and Code License: Sensor Web, GPL 2.0

Mentor: Henning Bredel (, Daniel Nüst (

Geodata search and exploration by visualizing data relations and dependencies

Explanation: GeoMetaFacet (live demo) is a web client to explore and visualize geodata that are stored in an OGC compliant Web Catalog Service (CSW). The huge amount of available geodata within GeoMetaFacet makes it sometimes hard to get an overview of available data and to find appropriate datasets or services. Although there are already implemented widgets such as a data lineage graph and a hierarchy tree, the application would benefit from more powerful and complex visualizations.

The student will implement innovative and interactive visualizations of geodata dependencies to improve search and exploration of geodata (in Javascript). These visualizations should illustrate dependencies of geodatasets and their properties (e.g. data topics, time series or publishing organizations) or about geodata relations (e.g. parent-child datasets, dataset-service). Challenges of the task are the identification of suitable visualization techniques (and implementations) and their integration into the existing interaction concept of GeoMetaFacet.

The student’s expertise should include web technologies, design experiences and relevant javascript frameworks such as dojo, d3.js, protovis or Google Charts. Depending on the student progress and interests,further implementation to include linked data techniques are possible.

Expected results: New visualization modules for GeoMetaFacet

Community and Code License: Metadata Management, Apache 2.0

Mentor: Christin Henzen (, NN

RESTful Event Notification API

Explanation: 52°North's Timeseries API (see code on GitHub) eases the integration of near-realtime sensor data into leigthweight clients. However, as just displaying sensor data falls too short for push-based event notification architectures, it has to be extended to include registration/management of users and subscribtion/management of events (e.g. sensor loss, or if measurements overshoot/undershoot a specific value). In the end the Timeseries API should be able to be combined with the 52°North SensorEventService as event engine.

The current event notification architecture is based on the extended SensorWebClient. This architecture is using GWT and based on tighly coupled RPC communication. Having a RESTful event notification management API decouples components and enable many devices to consume data served by the API (management from desktop applications or mobile application, etc.).

Students interested in this topic require good experience in Programming Java and an interest in working with web serivces and APIs.

Expected results:
  • For external access: RESTful extension to the Timeseries API with an event notification management interface
  • For data providers: An SPI to manage a data source where users/rules/subscriptions can be stored and managed (a dummy/default data sink is ok during development)
  • Either integrate event engine as structural component or use the SES as stand-alone service by using its Web interface
  • A simple user interface (similar to the TimeSeries API explorer) should also be developed for demonstration.
Further Reading: Community and Code License: Sensor Web Community, probably GPL2

Mentor: Henning Bredel (, Simon Jirka (, Matthes Rieke (

SOS Admin Interface for Importing Data

Explanation: The 52°North SOS includes a sophisticated web-frontend for the administration of the Service' configuration and metadata. However, there are reasonable scenarios where a service provides wants to expose existing data sources (e.g. CSV, Excel sheets, etc.) in a straightforward manner. 52°North has developed a standalone desktop application, the SOS-Importer, for these situations. However, a web-based on-the-fly integration targets the user's requirements and eases the general setup of a SOS instance. This project aims at developing a web-frontend for this purpose which should be integrated into the existing installation process as a last step. Besides the UI development, efforts on analyzing the given data in order to align it with the SOS database model are required.

Students interested in this topic require good experience in Programming Javascript (optimally: JQuery) and Java (optimally: JSP) and an interest in working with database models.

Expected results:
  • a web-based user interface for uploading existing data, aligned with the existing SOS installer
  • a logical layer for analysing the provided data to ensure compatibility with the SOS database model.
Further Reading: Community and Code License: Sensor Web Community, probably GPL2

Mentor: Carsten Hollmann (, Eike H. Jürrens (

SOS for CartoDB

Explanation: CartoDB is an open source platform to create amazing interactive maps. Just check out the examples on their blog. This project will connect CartoDB to the Sensor Web! This project will conduct the following milestones: Students should have good experience with Linux and experience with Ruby (or a similar programming language). Ideally the student has worked with CartoDB before or has some experience with geospatial data.

Feel free to join the discussion on the CartoDB mailing list:!searchin/cartodb/daniel/cartodb/Mma_BUwFLmY/bp55Fu7KMv0J

I also created a preliminary backlog on this idea once, hope it's useful: sos-for-cartodb-backlog.xls -- DanielNuest - 2014-02-25

Expected results: import geospatial data from the 52°North SOS with the importer wizard in CartoDB

Community and Code License: Sensor Web, Apache 2.0

Mentor: Daniel Nüst, NN

Progress status for WPS4R

Explanation: Geostatistics.WPS4R allows easy execution of R scripts as standardized WPS processes. For a good user experience, it is important that the WPS client can query the current process status to display a progress bar. Currently if an R process is executed the status information will jump from 0 to 100 %, and this shall be improved by allowing communication of status from R to the WPS. This status can then be queried as part of the WPS Execute operation (schema for response).

A student in this project shall extend the WPS4R implementation with features to query a process status from R, for example from (R, system) environment variables or from a simple text file in the R workspace. This information must be provided from an R script, so an R extension package wps4R must be developed that provides the functinality to store the current state of execution from R. An investigation of the existing R function txtProgressBar should also be conducted.

Required skills: Java software development, R extension package development (at least one of these areas with good expertise).

Expected results: wps4R R extension package, example algorithm (e.g. a loop through a data.frame) status can be queried from WPS service interface.

Community and Code License: Geoprocessing/Geostatistics, GPL v2

Mentor: Daniel Nüst (, NN

Customizable mobile application for on-line and off-line geodata capture

Explanation: Geodata capture with mobile phones and tablets has become common. However, many data collection exercises are hampered by (1) marginal telecom coverage (e.g., outside urban areas, in natural parks and in considerable parts of Africa) and (2) inflexibility of the app menu. The first problem could be avoided if the apps have off-line capabilities (and wisely use functionality available online). Then data can be stored locally until the device reaches a cell tower or a Wi-Fi hotspot. The second issue can be overcome if the app is easily customizable. The typical use cases we have in mind are wildlife mapping in national parks, water point mapping (e.g. monitoring water pump malfunctioning) and health mapping (registration of disease occurrences), all with the same modular app.

The ILWIS-objects framework is a C++ based modular software for geo-information handling, under development at 52°North's ILWIS community. This GSoC project aims at starting to deploy the ILWIS-objects framework on a mobile device.

Tasks of the student:
  • Develop a simple QT (QML based) client for Android for entering geodata
  • Setup the communication between server and client (two way)
  • Add off-line capabilities to the client
  • Introduce client-configurability for the different use cases
  • Validation, post and preprocessing of the data, using the ILWIS-Objects framework (optional)
Required skills: C++, knowledge of QML is considred a plus.

Expected results: Customizable mobile mapping application with off-line storage capabilities, acting as a client to an ILWIS service instance. The imlement a client/server application which can store and update points and simple attributes. Depending on the skils of the student the app can be extended to support lines and polygons as well as editing.

Community and Code License: ILWIS, Apache 2.0

Mentor: Martin Schouwenburg (, Bas Retsios (, Henning Bredel (

Web-based terrain tools

Explanation: Provide an application that allows Web-based modeling and analysis of terrain data as well as of other surfaces (e.g. interpolated groundwater levels, geologic strata etc.). Various interesting use cases exist, for example:
  • Paste point data measurements into your Web-browser, perform data interpolation on the server and receive a surface ready to be used on your mobile device.
  • Visualize a terrain model in your based Web-browser, interactively pick a vertex, and simulate simple flooding situations or trace "virtual drops".
  • Let the differences between terrain surfaces referring to other points of time be analyzed on the server.
The project is applicable for students starting at an intermediate level (Java and Javascript experiences required). Further useful skills: HTML/DOM, X3D.

Expected results: Java-based implementation of terrain services and a HTML5-based client as a demonstrator supporting interactive WebGL-based 3D-rendering inside the Web-browser

Tasks of the student:
  • Setup proper service interfaces
  • Java-implementation of terrain tool services based on the 52°North Triturus library
  • Realize HTML5/WebGL-based visualization (based on X3DOM) and implement JavaScript-based DOM access to 3D shape vertices/faces
  • Implement demo application (HTML5/CSS, JavaScript, DOM, Web-Services as Servlets or with REST interface)
Community and Code License: 3D, probably GPL2

Mentor: Benno Schmidt (, NN

Coarse Ideas

Project Template (add your idea above and leave this template intact)

<concise project title>

Explanation: <Shortly describe the idea and classify as specifically as possible including the required skill level, for example "tricky project, requires in-depth knowledge of database configuration" or "easier project, good for student with limited Java experience". Clarity and detail are highly desirable in the idea description.>

Expected results: <add here>

(NEW) Code challenge: <add here a short task for an interested student to demonstrate the capabilities with the used tools/producs, e.g. deploying the web server and changing behaviour of feature X.>

Community and Code License: <if applicable>

Mentor: <full name and contact details>

Topic revision: r35 - 15 Oct 2014, EikeJuerrens
Legal Notice | Privacy Statement

This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Wiki? Send feedback