Project Ideas for Google Summer of Code at 52°North in 2022

---

The is the ideas page for the Google Summer of Code 2022. If you are an interested student/contibutor please don't hesitate to contact mentors directly to discuss project ideas.

Information for Students/Contributors

General information: GSoCForStudents - please read before asking questions!

52°North is an open organization researching several topics in the field of Geoinformatics. Our staff members created the list of ideas below. Most ideas originated from different ongoing larger projects. We also welcome your ideas for projects related to our fields of activites and encourage you to get in touch with us to discuss these ideas.

How do I choose a project?

You will spend a consderable amout of time on the project this year, so make sure that you are really into it. This relates to various aspects of a project: the general idea, the mutual benefit of the development (also for yourself and not only for the community), the programming language used, etc.. Challenge yourself with one or more of the coding challenges - you will best realize if a software/framework interests you once you have some hands-on experience with it. If you have not found an idea that interests you on this ideas page, there are other organizations with great topics on geospatial technologies. Everything related to "geo" is the best in our opinion . So check out the ideas pages of like minded projects or come up with your own project idea (make sure to discuss it with us prior to developing a fully flaged proposal)!

What is the expected duration/size of the project?

All of following project ideas will make a meaningful contribution as medium GSoC project with an expected workload of 175 hours. However, if you envision a number of additional features to our project ideas that would increase the effort to a large GSoC project of 350 hours, present your ideas by email to the listed mentors before you submit your proposal. We can then discuss whether the project can be extended to a large one. Please note that the duration cannot be altered after the proposal submission deadline April 19 1800 UTC, i.e. not during the coding phase.

GSoC project ideas @ 52°North

OGC API clients and servers:

Explanantion: The Open Geospatial Consortium (OGC) is working on several API standards and has already released important parts of the OGC API - Features. In this years GSoC at 52°North, would like to implement clients of various programming languages (R, Python, JS, Java, ...) that are frequently used at 52N for different APIs. 52N will provide references to running API server that can be used to implement the clients. While the available services define the baseline, the standard specifications will be the true reference.

The use case is cross API integration, this means we want to check how well the data APIs (e.g. Features, Coverages) interact with the API - Processes (get features/coverages for processing, store results back in data API).

Further reading:

OGC APIs

javaPS (API - Processes server)

SOS4R (R client for OGC Sensor Observation Service)

QGIS Web Processing Service (WPS) Plugin (WPS is the predecessor of the API - Processes)

OWSLib (Python client API)

Required skills: Pick your preferred programming language or GIS framework, e.g. R, Python, JS, Java, or Quantum GIS (QGIS).

API Processes Client/Server

Of interest are clients implemented in R, Python, JS, Java, or a QGIS-plugin. An esri ArcGIS Pro plugin would also be thinkable, this would require a license that we could provide.

API Features Client

Of interest are clients implemented in R, Python, JS, Java, or a QGIS-plugin.

API Coverages Client/Server

Of interest are clients implemented in R, Python, JS, Java, QGIS-plugin and server implementations in Python (tailored to the Open Data Cube) and Java (general purpose library).

OGC Sensor Things API Clients

Of interest are clients implemented in R, Python, JS, Java, QGIS-plugin

Expected results (for all topis above): Improved, (fully) functional API clients in a different programming environments, ideally building on previous work and implementations.

Code challenge/proposal phase (for all topis above): Screen the open source resources and the OGC implementation site to identify the current state of implemented clients. Based on your review, propose additions and changes or new implementations in your proposal.

Community and Code License (for all topis above): Cross-community project(s). Apache Software License, Version 2.

Mentors (for all topis above): Benjamin Pross (b.pross @52north.org), Benedikt Gräler (b.graeler @52north.org) and further 52°North staff based on the selected programmin environment, eventually contributors of used open source libraries.

Python clients for OGC APIs

Explanation: Some OGC APIs do not have a client to interact with the various endpoints. Currently, developers have to make GET/POST requests using REST APIs. Developing a general OGC API Python Client will make this task easier and vcan be directly integrated into data analysis workflows. The main goal is to integrate the majority of APIs into a single client taking benefit from common definitions and patterns of the OGC APIs.

Expected results: A python client will enable developers to GET/POST data by using the python wrapper in their code. Requests to the API can also be made through a CLI tool developed specifically for the API.

Code challenge: Start the package development by one API of your choice and showcase the basi operations.

Community and Code License: cross-community project; MIT/ GNU GPL 2.0

Mentors: Benjamin Pross (b.pross @52north.org), Benedikt Gräler (b.graeler @52north.org)

Project duration: The duration of the project(s) can reach from 175 hours to 350 hours.

OGC API Processes: automatic process generation from R and Python Scripts

Explanation: Analysis of data is often developed in Python notebooks or R scripts. Once these processing scripts have emerged to a stable workflow, sharing them in a standardized form can result in an extra amount of work or even re-implementation. The OGC API Processes generalizes processes and provides a standardized API. In this project, a routine shall be developed, that extracts predefined leywords from an analysis script to wrap the script in an executable process.

Expected results: An OGC API Processes Server implementation (or extension) that allows to parse R scripts and/or python notebooks for qualifired keywords in annotations to turn them into OGC API processes.

Code challenge: Provide a draft concept of how the scripts need to be annotated to fully support the OGC API Processes standard. Show a proof of concept where an R script can be remotely executed via a REST Api.

Community and Code License: based software used, generally GPL 2.0

Mentors: Benjamin Pross (b.pross @52north.org), Benedikt Gräler (b.graeler @52north.org)

Project duration: The duration of the project is estimated 175 hours.

(OGC API) Geo Data Cube server based on Open Data Cube and pygeoapi

Explanation: Open Data Cube (ODC) is a project that aims at simplifying access to Earth Observation data. At its core it's a Python library providing an easy-to-use Python API for downloading EO data in an analysis-ready way (e.g. temporal, spatial and thematic subsetting, reprojection, sub-sampling). There is a server implementation supporting traditional OGC Web Services on top of ODC but no production-ready implementation supporting OGC APIs. A first step was made by implementing a provider plugin for pygeoapi (pygeoapi-odc-provider). pygeoapi is a Python server implemention of the OGC API suite of standards. In this project, the pygeoapi-odc-provider shall be further developed by implementing missing functionality, improving performance and robusteness and adding custom data extraction or analysis processing facilities.

Expected results: Improvement of the pygeoapi-odc-provider. Specific tasks can be discussed based on the interest and background of the student. Contributions to ODC or pygeoapi might also be part of the project.

Code challenge:

Community and Code License: pygeoapi-odc-provider (Apache License 2.0), pygeoapi (MIT) and Open Data Cube (Apache License 2.0)

Mentors: Eike Jürrens (e.h.juerrens @52north.org), Martin Pontius (m.pontius @52north.org), Benedikt Gräler (b.graeler @52north.org)

Project duration: The duration of the project is estimated 175 hours. An extension is possible.

---

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: Benjamin Pross (b.pross @52north.org), Carsten Hollmann (c.hollmann @52north.org)

Project duration: The duration of the project is estimated 350 hours.

GeoNode related projects

STA Integration in MapStore for GeoNode 4.0

Explanation: 52°North extended the GeoNode remote services to include data through the Sensor Things API (STA) in GeoNode 3.x. Curently, GeoNode's MapStore does not visualize this data source. I order to fully utilize the GeoNode framework, an integrated solution is in favour. During this project, the current implementation of the remote services for GeoNode 3.x shall be adapted to also support the forthcoming GeoNode 4.x release. Furthemore, data from a remote STA service shall be made avaiable in GeoNode's default MapStore Client as.

Expected results: GeoNode 4.x compatible implmentation of STA as a remote service along with an automatic visulaisation of the STA data in GeoNOde's MapStore.

Code challenge: Adapt the remote-service implementation of STA from GeoNode 3.x to GeoNode 4.x.

Community and Code License: GeoNode and STA, GNU GPL 2.0

Mentors: Eike Jürrens (e.h.juerrens @52north.org), Martin Pontius (m.pontius @52north.org), Jan Sculte (j.schulte @52north.org), Benedikt Gräler (b.graeler 52north.org)

Project duration: The duration of the project is estimated 175 hours. An extension is possible.

NetCDF support in GeoNode

Explanation: NetCDF -files are a common format for array shaped data in the Geo community and beyond. The GeoServer generally supports data from NetCDF -files, but this process is not yet fully integrated with GeoNode. During the course of this project, support of NetCDF -files (NetCDF -3 and NetCDF -4) shall be implemented into GeoNode along the entire pipeline from adding NetCDF -files as data sources to editing meta data, visualizing data, and exporting data as NetCDF -files.

Expected results: Thorough NetCDF -3 and NetCDF -4 support in GeoNode.

Code challenge:

Community and Code License: GeoNode and GeoServer, GNU GPL 2.0

Mentors: Eike Jürrens (e.h.juerrens @52north.org), Martin Pontius (m.pontius @52north.org), Benedikt Gräler (b.graeler @52north.org)

Project duration: The duration of the project is estimated 175 hours. An extension is possible.

enviroCar projects

enviroCar App: Replace View Binding and Event Bus libraries

Explanation: Currently, the enviroCar Android app uses Butter Knife, which is deprecated for some time. A recommended way for binding views is the View Binding library provided by Jetpack. In addition, the enviroCar app utilizes the event bus implementation of the library Otto, which also became deprecated for a while. Applying an event bus implementation based on RxJava and RxAndroid libraries would be more straightforward. In order to reduce the amount of boilerplate code and to follow best practices for view binding and eventing the enviroCar app should be adapted to use Android View Binding instead of Butter Knife and RxJava/RxAndroid approaches for implementing en event bus instead of using Otto.

Expected results: The deprecated Butter Knife view binding should be replaced by introducing Jetpack View Binding in order to provide a cleaner approach for separating views from models. In addition, an event bus implementation using RxJava/RxAndroid should replace the Otto event bus.

Code challenge: Replace Butter Knife view binding by Jetpack View Binding for the CarSelectionAddCarFragment.

Community and Code License: enviroCar, Apache Software License, Version 2.

Mentors: Sebastian Drost (s.drost @52north.org), Benjamin Pross (b.pross @52north.org)

Project duration: The duration of the project is estimated 350 hours.

Chat: https://gitter.im/enviroCar-app/community

enviroCar App: Voice Command

Explanation: Interacting with the enviroCar Android app while driving is a critical issue, since it may lead to accidents when the driver uses the smartphone. Adding voice command features to the app will significantly reduce this risk. However, Android Voice Actions only provide a small set of possible interactions with your app. It remains questionable whether Android voice actions are sufficient for providing useful voice interaction features or not.

Expected results: Integration of voice control into the enviroCar Android app for different interactions (e.g., start/stop recording, select a certain car). It remains open, if it should be done using Android out-of-the-box libraries, such as Voice Actions, or implementing a more dedicated solution by using a NLU engine (e.g., Rasa) in combination with Aimybox.

Code challenge: Propose a solution for integrating voice command into the enviroCar Android and outline an approach for the implementation. Possible solutions may be pure offline on-device implementations or a dedicated client/server approach by using an NLU engine. Also describe which open-source libraries you will use for the implementation.

Community and Code License: enviroCar, Apache Software License, Version 2.

Mentors: Sebastian Drost (s.drost @52north.org), Benjamin Pross (b.pross @52north.org)

Project duration: The duration of the project is estimated 175 hours. An extension is possible.

Chat: https://gitter.im/enviroCar-app/community

enviroCar Platform Independent App: Add UI for Data Privacy Settings/Control

Explanation: In the context of the SIMPORT Project we aim to add a UI for Data Privacy settings and control. The idea is to implement concepts developed in the SIMPORT project in the context of "informed consent". The user should be able to control the private and location-based data. As this project will be realized in a research context, the scope is not yet 100% defined but will be precised in the first weeks of the programme. More information on the concepts and the project are available as a scientic paper: https://www.tandfonline.com/doi/full/10.1080/17489725.2021.2017495

Expected results: UI for Data Privacy settings and control, in particular providing informed consent.

Code challenge: Get to know, what data is collected by the app. Implement a simple UI that informes the user about the collected data. Advanced: Implement a simple UI that lets the user check one or two data collection options. No real business logic is required here.

Community and Code License: enviroCar, Apache Software License, Version 2.

Mentors: Benjamin Pross (b.pross @52north.org), Matthes Rieke (m.rieke @52north.org)

Project duration: The duration of the project is estimated 175 hours. An extension is possible.

Chat: https://gitter.im/enviroCar-app/community

Your Project Here

You are also able to propose your own project. Note that this needs to be in the domain of 52°North.

We have numerous software projects that welcome new community members. Maybe you find something that interests you there:

52°North software projects, 52°North GitHub landing page

You should also propose a mentor for your project. Active mentors are:

Name	Email	Main skills
Benjamin Pross	b.pross @52north.org	Geoprocessing, Java, Android
Benedikt Gräler	b.graeler @52north.org	Data Analytics, R, Python
Christian Autermann	c.autermann @52north.org	Geoprocessing, Sensor-Web, Cloud, Java, Python
Carsten Hollmann	c.hollmann @52north.org	Sensor-Web, Java
Sebastian Drost	s.drost @52north.org	Java, Android, Python

Please use the following template:

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>