You are here: 52°North>Wiki>Projects Web>GSoC>GSoC2017ProjectIdeas (17 Mar 2017, SimonJirka)Raw Edit  | Attach

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

Main Page: GSoC2017

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

Simple Features for protobuf and others

Explanation: The Simple Feature Access Specification (aka. Simple Features) is a common standard for exchanging spatial features that is widely used in geoinformatics in Open Source projects as well as in proprietary programs. It defines a generic data model for storing and accessing geographic data and their geometry types. This specification includes data primitives such as Point, LineString, Polygon, various multi-versions of these geometries as well as a GeometryCollection. Beside of the data model specification, the standard also covers different representation formats of these geometries. These include the so-called Well-Known-Text (WKT) and Well-Known-Binary (WKB) formats.

In recent years, a lot of different binary-based serialization frameworks raised that allow a platform- and language-neutral way of encoding structured data for use in communication protocols, data storage etc. Some of these serialization frameworks are:

  • Protocol Buffers (aka. protobuf) developed by Google
  • Thrift developed by Facebook
  • Apache Avro
  • Messagepack

All these frameworks have their own characteristics and workflows in terms of serializing messages. Protobuf, for instance, requires the definition of so-called .proto schemas that describe the content of data objects to be serialized. A compiler is used to generate language- and platform-specific class-files from these schemas that perform the serialization process.

The aim of this project is to develop a serialization framework for transparently serializing simple features for multiple serialization frameworks in Java. Starting point is the so-called JTS Topology Suite (JTS), which is a free and open source library containing geometries that correspond to the Simple Feature Access Standard.

Required Skills: Java software development, experience in maven, knowledge of Java Topology Suite (JTS), protobuf or other serialization frameworks is a plus

Further Reading: Simple Feature Access Specification, protobuf

Expected results: Definition and implementation of a serialization API based on JTS, which transparently serializes geometries based on the Simple Feature specification using at least with protobuf. The API should be integrated as serialization option within the 52°North Sensor Observation Service (SOS) and/or Web Processing Service (WPS).

Code Challenge: Create or reuse a GeoJSON file of your choice containing at least two different geometries. Serialize and deserialize this GeoJSON file with protobuf.

  • Setup the development environment
    • Use the IDE of your choice
    • Create a Maven project
  • Create a JUnit test for the GeoJSON Geometry and serialize/deserialize the Geometry object
    • Get acquainted with the protobuf3 language guide
    • Create a .proto 3 schema for the Geometry (keep it simple but structured)
    • Take the GeoJSON File as input and validate the parsed Geometry.
    • Encode the geometry again.

Community and Code License: Geoprocessing, tbd.

Mentor: Arne de Wall (, Christoph Stasch (

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.

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 layed out.

Code Challenge: Build a simple Java programm 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: Apache Sofware License, Version 2

Mentor: Benjamin Pross (

Quality Assurance in enviroCar


The current version of the enviroCar dataset contains a few old tracks from earlier app versions that may contain missing or erroneous values. For example, an older version of the app combined with the CarTrend OBD adapter has generated erroneous speed values of 255 km/h in urban areas.

In order to filter out outliers or tracks with too many missing or erroneous values, a quality assurance mechanism should be implemented that allows for outlier detection and further quality assurance in both, the enviroCar App and the enviroCar server.

Another approach for assessing quality of enviroCar data is the use of external process models, e.g. implemented in R. The current output of enviroCar GeoJSON is modelled in a way that cannot be processed by major GeoJSON libraries without additional efforts. Thus an additional task in this project would be the creation of a more lightweight GeoJSON output format that is supported by third party processing libraries.

Expected results:

The following results are expected:
  • extensions for automated quality assurance in a generic way in enviroCar app and/or server
  • new quality filters should be easily integrated in the extensions
  • simplified, lightweight GeoJSON output encoding
Code challenge:
  • Setup mongo DB with provided test dump
  • create script for filtering values within certain value range and delete tracks wich contain more than 40 percent of measurements matching that filter
  • simplify execution of script outside mongo shell, e.g. by defining the value range using a form in an UI and then clicking an execute-button to run the script
Complete the challenge, please send to the mentors a zip file with script, installation descriptions for the UI and relevant documentation or provide a link to a repository where the required items can be found.

Community and Code License: enviroCar, AGPL v3 (server), MIT (JavaScript)

Mentors: Arne de Wall (, Matthes Rieke (, Christoph Stasch (

OGC TimeseriesML XML streaming encoder for svalbard

Explanation: The OGC TimeseriesML 1.0 standard was published in September 2016 and contains an XML encoding specification for time series data. The 52°North's Java framework for de-/encoding of OGC web services requests/responses, named svalbard, provides XML de-/encoder which are used by the 52°North SOS and WPS but futher projects are under development that uses this framework. Currently, the XML de-/encoder are mainly use the retired Apache XMLBeans which is not very performant for hugh datasets. Besides the implementation of an XML streaming encoder for OGC TimeseriesML this project also includes the exchange of the existing XMLBeans encoder against XML streaming encoder.

This GSoC project comprises the following tasks:
  • analyze the existing implementations (52°North svalbard and SOS)
  • implement OGC TimeseriesML XML streaming encoding for 52°North svalbard
  • exchange existing XMLBeans encoder against XML streaming encoder
This is a project with medium to high complexity. To work on this project you will need experience with Java development, Maven and Spring.

Expected results: The result will be a new OGC TimeseriesML XML streaming encoder and the exchange of the existing XMLBeans encoder against XML streaming encoder.

Code challenge: Build the current version of the 52N svalbard and implement a basic version of the TimeseriesML XML streaming encoder that returns a Timeseries element. Send the created TimeseriesML encoder class file to the mentors of this project. In case of any questions, please subscribe to the 52°North Sensor Web/SWE mailing list.

Community and Code License: Sensor Web, Apache License 2.0

Mentor: Christian Autermann (, Carsten Hollmann (

Geoservices REST-API for SOS

Explanation: The 52°North SOS is a web service for providing interoperable access to measurement data (it is based on the OGC Sensor Observation Service standard). This standard specifies several HTTP GET/KVP or HTTP POST/XML requests to retrieve measurement data from an SOS server. However, in addition to these bindings, REST is becoming a more and more popular concept for offering resources (in this case: observation data) on the Web. A powerful REST-API for geospatial data and operations is the GeoServices REST Specification ( The task in this project is to develop a new binding for the 52°North SOS server that conforms to the GeoServices REST Specification so that users can download measurement data/metadata.

Within this project, you will need to understand the SOS interface and develop an approach how the functionality/data offered by an SOS server can be mapped to the GeoServices REST Specification. Based on this approach you will enhance the current 52°North SOS server 5.x implementation. This is a project with rather complexity. To work on this project you will need experience with Java development as well as REST.

Expected results: Implementation of a new binding for the 52°North SOS that fulfills the GeoServices REST Specification. This implementation shall reach a maturity level so that it is ready for integration into one of the SOS releases after GSoC 2017.

Code challenge: Build the current version of the 52N SOS and deploy it on your computer. Please send the GetCapabilities response of your server after successful installation to the mentors of this project. After that get to know the 52N SOS source code and implement a prototypical Binding class for the GeoServices REST Specification that decodes the RESTful FeatureService request (9.0.x of the GeoServices REST Specification) and returns a JSON encoded response as defined in chapter 9.0.x of the GeoServices REST Specification. The JSON response should be created by using the 52N SOS JSON coding classes. If necessary, the 52N SOS JSON coding classes should be extended. Send the created Binding class file and an examplary request and response (JSON) to the mentors of this project. In case of any questions, please subscribe to the 52°North Sensor Web/SWE mailing list.

Community and Code License: Sensor Web, GPL v2

Mentor: Simon Jirka (, Carsten Hollmann (

OPeNDAP backend for SOS

Explanation: The 52°North SOS is a web service for providing interoperable access to measurement data (it is based on the OGC Sensor Observation Service standard). Currently, our SOS implementation is mainly relying on database servers to store measurement data. However, in many domains, OPeNDAP is commonly used as an approach for file-based storage of observation data (e.g. because of huge data volumes which are not suited for regular databases). Thus, an approach is needed, how the 52°North SOS can use OPeNDAP as an alternative to databases.

This GSoC project comprises the following tasks:
  • analyze the existing implementation
  • develop an abstraction layer (data access object) to support OPeNDAP servers in the 52°North SOS
  • add OPeNDAP support to the latest 52°Nort SOS development line relying on the abstraction layer you will develop
  • enhance the web-based administration interface of the 52°North SOS so that a user can manage/configure the OPeNDAP servers which shall be used as data source.
This is a project with medium to high complexity. To work on this project you will need experience with Java development, Maven and JavaScript.

Expected results: The result will be a new Data Access Object (DAO) module for the 52°North SOS so that the SOS can serve content provided by OPeNDAP servers. Furthermore we expect an enhanced administration interface of the SOS to configure and manage the OPeNDAP servers the SOS shall use as input.

Code challenge: Build the current version of the 52N SOS and deploy it on your computer. Please send the GetCapabilities response of your server after successful installation to the mentors of this project. After that get to know the 52N SOS source code and write a GetObservationDAO class that reads the data of the Extended Reconstructed Sea Surface Temperatures file from the OPeNDAP server. Send the created GetObservationDAO class file to the mentors of this project. In case of any questions, please subscribe to the 52°North Sensor Web/SWE mailing list.

Community and Code License: Sensor Web, GPL v2

Mentor: Christian Autermann (, Carsten Hollmann (

Cross-domain sensor data for ArcGIS

Explanation: The Sensor Observation Service (SOS) extension for ArcGIS for Server is implemented as a Java Server Object Extension (SOE). Currently it supports the provision of air quality data in the e-Reporting XML schema through the SOS interface. This data is stored on top of a specialized database schema. In order to be able to support additional data from other domains (e.g. hydrology) the data access layer as well as the XML encoding layer need to be extended.

This task requires good experience in
  • Java: JUnit tests, development and API design
  • database management systems (MS SQL Server, PostgreSQL)
  • database schema design
  • ArcGIS for Server 10.1+ administration
Further requirements: The student needs access to a development environment featuring ArcMap and ArcGIS for Server (10.1+) - get in touch with the mentors if this is not available in your school.

Expected results: The outcome of this project equips the ArcGIS-Server-SOS-Extension with extensible capabiltiies on providing data from domains beyond air quality. You will help to make the project more sustainable and reliable by developing unit tests and on top of that design new layers for data access.

Code challenge:
  • Setup the development environment:
    1. create an ArcGIS for Server Feature Service on top of the provided MS SQL Server sample database
      1. you can use MS SQL Server Express (2008R2 and updwards)
    2. checkout and build the ArcGIS-Server-SOS-Extension project
    3. install the built SOE extension into the ArcGIS for Server instance
    4. enable the SOE extension on the ArcGIS for Server Feature Service (see step 1)
    5. report/provide the output of a given GetObservation-Request ( of this form)
  • Create a JUnit test for the class OGCObservationSWECommonEncoder
    1. Get a feeling on how a response to the #encodeObservations() looks like
    2. Implement Asserts against the markup (e.g. using XPath expressions, XMLBeans, ...). Possible examples:
      • //om:result/swe:DataArray/swe:elementCount/swe:Count = 24
      • //om:observedProperty/@xlink:href = ""
To complete the code challenge send the mentors a zip file containing the output of the GetObservation request from the ArcGIS feature request, a screenshot of the ArcGIS server SOE configuration, and the Java class with the unit tests.

Community and Code License: Sensor Web, ASL 2.0

Mentors: Matthes Rieke ( and Simon Jirka (

Caching for Sensor Web REST API

Explanation: In many use cases on the Web high responsive clients are a must. However, within the Sensor Web timeseries data can become very large quite often (sensor data measured by minute year-by-year). To keep user experience of light Web clients on an acceptable level solutions have to be developed to tackle this problem. The main goal of this project is to improve the performance of serving in-situ data available from the lightweight (RESTful) Sensor Web API. Since the complexity of a Sensor Web architecture, this can target several components. Which one to choose, depends on the concrete components used in such an architecture. Here, we focus on the stand-alone proxy Web application.

Interested students need to understand the Sensor Web REST API and how it can be applied in several Sensor Web architectures. Experiences with Java (Web services), Maven, Git, Spring, and RESTful Web interfaces (including caching) is a matter of course. This is a project with medium to high complexity. To work on this project you need experience with Java development.

Expected results: Within this project a caching module shall be implemented which is modular and can be configured via xml files similar to other functionality of the Series REST API. The cache must be stored in a RAM-based database and should be cleaned up regularly. Cached and not cached data (e.g. outside cached timespan) shall be recognized and missing data have to be requested and cached in a smart way.

Output shall be a module which can be optionally integrated into the REST API via Spring injection.

Code challenge 1:
  • Get acquainted with the Sensor Web REST API.
  • Checkout the JavaScript Client to access series data via Sensor Web REST API
  • Have a look how request handling is done and come up with suggestions how the requests can be optimized to reduce network traffic
Code challenge 2: Community and Code License: Sensor Web Community, GPL

Mentors: Henning Bredel (, Jan Schulte (, and Simon Jirka (

Draft Ideas

Coarse ideas and general goals

  • full streaming from database (via SOS+proxy or via TS-API) to JavaScript client
  • Add WPS 2.0 support to WPSClient4ArcGIS
  • 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
  • Simple Features for protobuf and others

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: r13 - 17 Mar 2017 13:28:07, SimonJirka
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