You are here: Wiki>Projects Web>GSoC>GSoC2018>GSoC2018ProjectIdeas (19 Mar 2018, ArneDeWall)Edit Attach

Project Ideas for Google Summer of Code at 52°North 2018

Main Page: GSoC2018

The is the ideas page for the Google Summer of Code 2018. 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!

Information for Students

General information: GSoCForStudents

52°North is an open organisation with several "communities" on specific topics. The list of ideas below was created by the community leaders and code managers of different projects organized within these communities. The "Draft Ideas" section contains ideas still under discussion between mentors and org admins, or incomplete ideas, so please get in touch before starting the code challenge.

Beyond our ideas, we welcome your ideas for projects related to our communities and encourage you to get in touch with the communities on the respective mailing lists to discuss your own project ideas.

How do I choose a project?

Some of the software projects are available pre-built on the OSGeo Live demo, including project overviews and tutorials where you can try everything out. Download the ISO from If you have not found an idea that interests you on this ideas page, there are other organisations with great topics on geospatial technologies, and everything related to "geo" really is the best in our opinion. So check out the ideas pages of like minded projects: OSGeo, OpenStreetMap.

Challenge yourself with one or more of the coding challenges - you will best realize if a software interests you when you have some hands-on experience with it. And that is the most important part: you must really find the project interesting.

Ready ideas

Rich Data Interface for Copernicus Data

Explanation: Copernicus is a European Earth observation programme with the goal “to provide accurate, timely and easily accessible information to improve the management of the environment, understand and mitigate the effects of climate change and ensure civil security” (ESA 2015). Within Copernicus, a series of new satellite missions will be executed to gather new satellite data. The first mission acquiring radar data, called Sentinel-1, and the second mission gathering multi-spectral high-resolution data have already been launched.

The Sentinels Scientific DataHub is one of the central points, which provides free and open access to Sentinel-1 and Sentinel-2 user products. However, this infrastructure only releases up to Level-1C products to the users (see here). In order to derive higher-level information products (e.g. Level-2A), the data needs to be processed on the user side, e.g. by using segmentation algorithms. In former times, this workflow included downloading the data, pre-processing it by selecting the spatial and/or temporal extent, and then running the actual segmentation process.

For the processing of sentinel data, there exist SNAP, which is a common toolbox consisting of a rich set of visualization, analysis, and processing tools for the exploitation of Sentinel data. In addition, SNAP has a build-in graph processing framework (GPF) that enables the creation of user-defined processing chains.

Aim of this project is to make use of these processing facilities and to provide a rich data interface for deriving new information products (Level-2) from Sentinel data. Therefore, an OGC Web Processing Service that makes use of the SNAP toolbox needs to be implemented. The WPS should independently download the data from any data infrastructure providing Sentinel data (e.g. scihub, AWS) and should be able to apply user-defined function chains based on SNAP’s built-in GFP framework.

Required skills: Java software development, knowledge of processing libraries, e.g. GeoTools, and tools for data transformation, e.g. SNAP and GDAL, basic knowledge about remote sensing and related information.

Expected results: An implemented Web Processing Service that provides a Rich Data Interface for Copernicus data. The WPS should be able to defined processed based on SNAP’s built-in GFP framework. Furthermore, the WPS should offer at least two different ready-to-use processes, e.g. segmentation process and a process for deriving an index (e.g. NDVI).

Code Challenge: Checkout the sources of the latest version of the 52N WPS and implement an algorithm based on SNAP (e.g. NDVI index) that provides data from copernicus (e.g. Sentinel 1 or 2 data) for a specific bounding box, i.e. that process has as input parameter a bounding box and returns Sentinel data as output.

Community and Code License: Geoprocessing/Geostatistics, GPL v2

Mentor: Arne de Wall (, Benjamin Pross (

WPS 2.0 support for the WPS Client for ArcGIS

Explanation: The Web Processing Service (WPS) Client for ArcGIS was first released in 2013. It was developed in Java by Benjamin Pross together with Alber Sanchez, who received the "Student of the Year" award from the Institute for Geoinformatics in its role as ESRI Development Center (EDC). The support of the open WPS interface standard, version 1.0.0 unlocks a wide range of web-based geoprocessing functionality to ArcGIS users. The offered functionality covers simple tasks like buffering up to complex environmental models. The WPS is used by organizations like the USGS or CSIRO. Currently, the recent WPS standard version 2.0 is not supported by the client. This project is supposed to remedy this.

Further reading: WPS Client for ArcGIS on GitHub, WPS Java Client library on GitHub, WPS 2.0 Interface Standard

Required skills: Java software development, optional: experience with ArcObjects, experience with OGC Web Services.

Required software: ArcGIS for Desktop 10.x. Please try to obtain a free trial version to complete the code challenge. Successful applicants can be provided with a research license, if needed.

Expected results: The WPS Client for ArcGIS reliably works with WPS 1.0.0 and 2.0 servers. The basis for further interfaces like WPS REST should be laid out.

Code Challenge: Build a simple Java program that can connect to WPS 1.0.0 and 2.0 servers and that lists the available processes. Present an idea (e.g. UML diagram) of the necessary abstraction layer. Use XMLBeans or streaming de-/encoder for parsing/generating the XML (the latter is more advanced, have a look at javaPS for ideas).

Community and Code License: Geoprocessing Community, Apache Software License, Version 2

Mentor: Benjamin Pross (

.NET WPS Client for ArcGIS Pro

Explanation: The Web Processing Service (WPS) Client for ArcGIS written in Java (see project idea above) was first released in 2013. However, the support for Java was dropped in the new ArcGIS Pro software. So a new client is needed written in .NET, to be ready for the future. Some concepts from the Java-based can be taken over, while others need to be updated.

Further reading: Java-based WPS Client for ArcGIS on GitHub, ArcGIS Pro SDK Community Samples WPS 2.0 Interface Standard

Required skills: .NET software development, optional: experience with ArcObjects .NET, experience with OGC Web Services.

Required software: ArcGIS Pro. Please try to obtain a free trial version to complete the code challenge. Successful applicants can be provided with a research license, if needed. Check here for a free trial: ArcGIS Pro Free Trial

Expected results: The WPS Client for ArcGIS Pro reliably works with WPS 1.0.0 and 2.0 servers. The basis for further interfaces like WPS REST should be laid out.

Code Challenge: Create a basic project structure for the client. It should feature a simple GUI, where you can select a Web Processing Service by URL. Methods for sending a GetCapabilities -request via KVP should be implemented and the basic service capabilities (e.g. tile and processes) should be displayed.

Community and Code License: Geoprocessing Community, Apache Software License, Version 2

Mentor: Benjamin Pross (

Combining Helgoland with Shiny and R

Explanation: Helgoland is a product from of the 52°North software suite acting as a web-based fronted to an OGC sensor observation service (SOS). As such, Helgoland comprises different views and selection operations on the sensor data stored in the SOS. This includes a map view/selection, list selection and time series plots and table views. Shiny Apps can bundle a lot of R's analysis capabilieties in handy web applications. The aim of this projet is to merge these two tools to add direct analysis capabilities to the Helgoland SOS viewer.

Required skills: Java Script; R, i.e. Shiny extensions

Expected results: a full feature Shiny integration with 52°North's Helgoland SOS viewer

Code challenge: Providing a shiny application interacting with some SOS instance and performing a set of analysis tasks where the time series selection is based on the Helgoland client.

Community and Code License: Spatio-Temporal Data Science Community, Apache Software License, Version 2

Mentors: Ben Gräler (, Jan Schulte (, Simon Jirka (

Trajectories in R

Explanation: Currently, several R packages exist that deal with trajectory data in R. Some deal mainly with the data structure of trajectories while others provide access to trajectory data sets and a couple of packages is designed for the analysis of trajectory data. This GSoC project aims at unifying this landscape and adapting to recent developments in the spatial/spatio-temporal data handling in R (i.e. sf). The R package shall provide generic classes, methods and tools for handling and analyzing large-scale trajectory data with R. Data from the enviroCar API will be taken as example data.

Required skills: R (i.e. package design), some background in computational geometry and/or (geo-)statistics.

Expected results: Classes and methods for handling trajectories in R, building on recent developments in the spatial/spatio-temporal data handling in R (i.e. sf). Low-level manipulation will involve selection, aggregation (to a lower spatial and/or temporal resolution), sampling, simple (linear) interpolation and visualisation (animation, space-time cubes, projections, ...). Analysis methods will include computation of several attributes (speed, direction); computing distances between trajectories; package should be ready for submission to CRAN.

Code challenge: Provide a R package with a trajectories data structure that extends sf. The package shall be capable of quickly importing a set of enviroCar trajectories from the enviroCar server. Furthermore, the package shall provide functions to compute meaningful distance measures between single tracks. Provide proper documentation (clean CRAN checks).

Community and Code License: Spatio-Temporal Data Science Community, needs to be determined (maybe GPLv3)

Mentors: Ben Gräler (, Arne de Wall (

Plain GPS-based Recording for enviroCar

Explanation: enviroCar is an open platform for collecting and analyzing car driven tracks. The collected tracks consist of GPS positions enriched with additional raw sensor data as well as derived information (e.g. CO2 emission and fuel consumption) by utilizing the inertial diagnostic capabilities of vehicles. This raw sensor data is collected by the use of the so-called On-Board-Diagnostics systems of vehicles.

The current recording procedure of the enviroCar Android app heavily relies on the connection to an OBD-II adapter. Thus, a track only gets recorded when a stable bluetooth connection to an OBD-II device exists. However, trajectory data without additional raw sensor data of cars is still a very valuable source of information for further analysis (e.g. traffic flow).

Aim of this project is to implement OBD-less recording of tracks in the current enviroCar Android application. On the one hand this requires a proper integration of this specific recording style into the application logic. As a major challenge in this part is to develop and evaluate strategies on how to make sure that the app is recording a track of a car (e.g. activity recognition). On the other hand, the developments need to be visually embedded into the GUI of enviroCar.

Required skills: Android software development, knowledge of modern development paradigms and frameworks for Android (RxJava, Dagger, ActiveAndroid, Otto, etc.), good command of UX development for Android, some experiences with activity recognition libraries of google (if these are applicable)

Expected results: An additional recording mechanism for enviroCar tracks based on plain GPS. A proper integration into the GUI of the app following novel UX design guidelines. Further strategies for automatic recording (e.g. based on Activity Recognition, see Google Play Services )

Code Challenge: Checkout the sources for the enviroCar Android app and integrate a routine for plain GPS-based recording of tracks. This also includes a proper integration in the GUI of the enviroCar app.

Mentor: Arne de Wall (, Christoph Stasch (

Dynamic Street Segment Statistics for enviroCar

Explanation: The enviroCar platform provides access to a huge amount of floating car data, providing the possibility to infer useful patterns and trends. A very useful and simple approach to access these patterns is to compute aggregated statistics based on street segments (e.g. OpenStreetMap). A first experimental setup for streetsegment-based aggregations been realized based on GeoMesa, which is an open-source spatio-temporal big data store based on Apache Accumulo + Hadoop HDFS. You can see the outcome of this processing in the map on this site for the area of germany. However, this layer provides just a static and flat view on the global average statistics of some particular dataset. Dynamics in this solution are lacking so far.

The aim of this project is to make this solution more dynamic. On the one hand, this includes a dynamic ingestion of the enviroCar data from the enviroCar server to the GeoMesa backend including the map-matching of tracks and the updating of statistics. This could be done, for instance, by making use of the stream-processing capabilities of Apache Kafka & Apache Storm. On the other hand, the storage of all data needs to be adjusted in order to allow the generation of more dynamic aggregations and statistics (e.g. avg statistics per year, under the week or during weekends).

Required skills: software development skills in Java; knowledge of GeoTools and GeoServer; very good command of Docker; shell scripts

Expected results: Dynamic ingestion of new tracks from the enviroCar Server to the GeoMesa backend (enviroCar-Server push mechanism + GeoMesa ingestion); reactive map-matching of new tracks (map-matching procedure already exists); adjustments to the database scheme allowing the generation of more dynamic statistics; Dockerfiles + docker-compose to setup the infrastructure; proper documentation of every single step;

Code Challenge: Getting Ready: Get familiar with GeoMesa and how the ingestion of data works (see here). You can use geodocker to setup your own infrastructure (see here); Code for the MapReduce based ingestion of enviroCar data can be found here. Ingest some of the enviroCar data to get a rough understanding of how GeoMesa in combination with enviroCar looks like. Configure the GeoServer and inspect your ingested data (see GeoMesa documentation; ask for advice if you need help).

The Challenge: Extend the existing implementation to allow the plain ingestion of enviroCar with Apache Kafka & Apache Storm (see here); Write a minor test client, which is able to push new tracks from the enviroCar API to Apache Kafka/Storm which then gets ingested to the GeoMesa backend (map-matching is not required); Document every single step or make a screen recording of your solution; provide a rdy-to-test setup consisting of dockerfiles, docker-compose and/or shell scripts;

Mentor: Arne de Wall (, Christoph Stasch (

UI for the Arctic Sea settings API (Faroe)

Explanation: The faroe API of the Arctic Sea framework lets you set the properties for OGC services (e.g. Service Identification and -Provider, see this Capabilities document: Capabilities). The settings are stored in JSON files. This project should create a Web-frontend to create, read, update and delete (CRUD) the JSON settings. The frontend should be written in JavaScript. Also, a REST API will be needed on top of the faroe API. The UI should be easily extensible (for example see the properties for the javaPS Well-known text (WKT) parser) and customizable, e.g. with customer logos.

As an optional extension, Faroe could be extended to run as a standalone service. It should offer an API (e.g. based on WebSockets) to subscribe to setting changes and provide a implementation of SettingsService that uses a remote instance of Faroe for configuration.

Required skills: software development skills in Java and JavaScript

Expected results: UI components and a REST API for the faroe settings API

Code challenge: We expect the basic components (JavaScript UI, REST API) to be there to have a good starting point for the project. A simple form to set one or more service settings via a rudimentary REST API.

Community and Code License: Cross-community project. Apache Software License, Version 2.

Mentors: Christian Autermann (, Benjamin Pross (, Carsten Hollmann (

WPS Client for R

Explanation: Various processing functionalities are exposed as public or internal Web Processing Services (OGC WPS) that wrap complex models or simply standardize approaches. Directly assessing these WPS via a simple R interface from inside R (nicely linked with state of the art spatial and spatio-temporal data structures) would ease the (re-) use of WPS for a wider community and allow to outsource typical operations. The project shall not only focus on the WPS R Client, but also on a shiny extensions/application, that nicely integrates the building blocks to elevate the WPS R Client to a modern and versatile web application.

Expected results: An R package available from CRAN that allows easy access to WPS functionality in an R-like fashion and (possibly as separate R package) a shiny extension/application

Code challenge: Community and Code License: Geoprocessing and Spatio-Temporal Data Science. Apache Software License, Version 2.

Mentors: Benedikt Gräler (, Benjamin Pross (

bi-directional binding between openHAB and SOS

Explanation: openHAB is a "a vendor and technology agnostic open source automation software for your home" that is easily extensible by user provided bindings. To increase the set of possible environmental input variables that trigger actions in your smart home, this project shall develop a bi-directional binding between the OGC-standardized SOS and the openHAB API. Besides retrieving data from a SOS (e.g. gauge data from a close by river, precipitation, water temperatures, ...), parameters from the smart home shall also possibly be mapped in to a SOS.

Expected results: a bi-directional binding between openHAb and the SOS (and possibly other OGC standards)

Code challenge: provide a openHAB binding that allows to integrate phenomena from a SOS into openHAB.

Community and Code License: Sensor Information Infrastructures; TBD

Mentors: Benedikt Gräler (, Simon Jirka (

Draft Ideas

Coarse ideas and general goals

  • full streaming from database (via SOS+proxy or via TS-API) to JavaScript client
  • try to combine project requirements (= mentor effort provided) with motivating (fun, interesting) projcts -- ARE via DanielNuest - 2014-10-02
  • Usage statistics and performance evaluation of WPS, SOS and Timeseries API using the ELK stack (comprises new logging configuration, instructions, logging statements to capture all required information) -- DanielNuest - 2015-02-10
  • IOs version of enviroCar app
  • enviroCar website
  • PhoneGap für JS client
  • SOS.js for SOS 2.0 based on ows.js
  • Access control for Sensor Web REST-API
  • WPS client library in C#
  • Admin UI for javaPS
  • WPS Docker backend
  • WPS Clients for GRASS GIS, QGIS, ...

Project Template

Please copy and paste to the drafts section above and get in touch with the org admins - 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>

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>

Mentors: <full name and contact details>

Topic revision: r21 - 19 Mar 2018, ArneDeWall
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