You are here: Wiki>Projects Web>GSoC>GSoC2019ProjectIdeas (15 Mar 2019, ArneDeWall)Edit Attach

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


The is the ideas page for the Google Summer of Code 2019. 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 http://live.osgeo.org. 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

Angular WPS Client library

Explanation: The Web Processing Service (WPS) JavaScript library written in JavaScript was first released in 2014. However, the wps-js library does not fully support all WPS features and typings for TypeScript -based Clients like Angular are missing. Hence, a new TypeScript -based Angular WPS Module is needed for the future. Some concepts from the JavaScript -based wps-js library can be taken over, while others need to be updated and additional missing WPS features need to be implemented.

Further Reading: JavaScript-based WPS library on GitHub , OGC WPS 2.0 Interface Standard (Document 14-065) and Web Processing Service (Document 05-007r7)

Required Skills: Angular 7 or 8, TypeScript, optional: experiences with OGC Web Processing Services

Expected results: The Angular WPS Client library reliably works with WPS 1.0.0 and 2.0.0 servers, supports XML POST Binding Extensions and Dismiss Extension, and comprehensively provides TypeScript typings for WPS responses and their properties.

Code challenge: Create a basic Angular 7(8) project module with a WPS library service. The service should provide a WPS constructor consuming URL and VERSION of a WPS server. A Method for sending a GetCapabilities -request should be implemented and it's return should be a 'capabilities' TypeScript class. The capabilities object should contain (at least) the array of processes, where each process is a TypeScript class containing 'identifier', 'jobControlOptions', and 'outputTransmission' as Strings (or Arrays of Strings).

You can test your implementation with a demo wps supporting both versions (1.0.0 and 2.0.0) at http://geoprocessing.demo.52north.org:8080/wps/WebProcessingService

Community and Code License: MIT License

Mentors: [Benjamin Pross (b.pross@52north.org)]

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 (b.graeler@52north.org), Benjamin Pross (b.pross@52north.org)

Python Analytics Toolbox for enviroCar

Explanation: enviroCar is an open platform for collecting and analyzing floating car data (xFCD). The collected data consists of GPS position enriched with additional sensor information by utilizing the vehicle’s internal diagnostic capabilities. All data that has been collected and uploaded to the enviroCar server is freely published under the Open Database License (ODbL). The general aim of the enviroCar project is to provide an citizen science platform with many possibilities to analyze the data.

Python has become a trending topic for data science in recent years. Especially Jupyter notebooks are powerful tools that have become very popular to data scientists in recent years. While enviroCar already provides many possibilities to analyze the data (e.g. in the enviroCar mobile App, WebApp, processing services, R package, etc.), a simple integration into Jupyter notebooks is not yet possible. The course of the enviroCar platform in this year, however, is to extend the analytical capabilities of the platform and a python toolbox is one of the focuses.

This project aims to initialize a python toolbox for accessing, processing, visualizing, and interacting with enviroCar data. The toolbox should be able to request data from the enviroCar API, store it in python specific data structures such as numpy or pandas, provide some possibilities for processing the data and plotting (e.g. matplotlib, seaborn, etc.) or visualizing it on a map (e.g. ipyleaflet, bokeh). Beside the basic functionalities, the toolbox should also cover possibilities to derive basic statistics of individual tracks/a set of tracks (e.g. average speed, stop times, number of stops, etc.), and some advanced processings (e.g. MapMatching with for instance OSRM, Hot-Spot analyzes, etc.). Another possible part could be to use the reticulate R interface to Python in order make the algorithms available in python.

Proposals for this project are expected to cover some nice ideas for the core of the implementation and also a concrete plan which advanced algorithms are to be implemented.

Required Skills: Good Python 3 programming skills (especially OOP), very good experience in data science typical python libraries (e.g. numpy, (geo-)pandas, matplotlib, seaborn, etc.), experience with Jupyter Notebooks

Excepted Results: Python Toolbox for enviroCar that allows to request data from the enviroCar API, stores the data in python typical data structures, and that provides some basic plotting and visualization capabilities. In addition to that, the toolbox should also provide advanced means of (pre-)processing tracks such as MapMatching, similarity measurements or different ways of spatial/temporal aggregation.

An additional R intergration via reticulate is a nice-to-have and depends on the proposal of the student.

Code Challenge: Write a single jupyter notebook that requests data from the enviroCar REST API and visualizes the data on a map and within graphs. Perform various analyses based on single and multiple tracks that make sense to you. You are free to use any python package you like. Try to exemplify in your notebook on how you want to deal with the enviroCar data during GSoC. Make first attempts on how you want to structure the final python package. Add markdown describing your ideas in more detail.

Mentor: Arne de Wall (a.dewall@52north.org), [Benedikt Gräler]

Binary Encoding for enviroCar

Explanation: The current data format in communication with the enviroCar server is based on JSON. However, this exchange format is not the most efficient choice. Especially for very long journeys, this encoding tracks tends towards very long serialization times and exchange sizes, contrary to the general strategy in handling mobile devices.

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. These frameworks allow memory efficient serialization under high speed that significantly outperform traditional encodings such as XML or JSON. Some examples include protocol buffers (aka. protobuf) developed by Google, FlatBuffers, Apache Avro, Messagepack.

The aim of this project is to implement an additional binary encoding for the enviroCar ecosystem. In general, this requires requires adaptations to the serialization layer of the enviroCar Server and the enviroCar Android app. Adaptations to other components such as the enviroCar WebApp are optional and not required.

Required Skills: Android and Java software development, experience in building RESTful services, understanding of Maven&Gradle build management tools, experience in protobuf, Jersey

Expected Results: Definition and Implementation of an binary encoding for the enviroCar API. This includes corresponding schemas and a proper integration in both the enviroCar mobile app and the enviroCar Server. The implementation of tests is a matter of course.

Code Challenge: Setup a local instance of the enviroCar Server and complete the implementation with a binary encoding for a single element from the enviroCar API of your choice (e.g. Measurement). An restricted dump of the MongoDB database containing some test data can be found here. In addition, write some tests and provide a Postman collection for testing along with the packaged .war file of the server.

Mentor: Arne de Wall (a.dewall@52north.org), [Christian Autermann]

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 (a.dewall@52north.org)

Improve enviroCar Android User Interface & User Experience

Explanation: The difference between a good app and a bad app is usually the quality of its user interface (UI) & user experience (UX). A good UI/UX is what separates successful apps from unsuccessful ones. Today, mobile users expect a lot from an app: fast loading time, ease of use and delight during the interaction. A more usable app is high on user engagement and has reduced chances of app uninstalls. Better UI/UX with increased user retention is one of the prime reasons for app evangelism too.

The current enviroCar project has the following limitations :

  1. There is a lot of potentially visualizable open data present in the enviroCar API, which can be visualized for better user experience.

  2. It is tedious to traverse through the recorded tracks in “My Tracks” tab if there were too many tracks recorded. So it is expected to solve this issue in any manner(for eg. by adding some filtering capabilities)

  3. Report Issue screen is very naive, which can be improved by designing a better UI.

  4. Many old versioned libraries were used in the repository.

The aim of this project is to redesign the UI of the enviroCar android application by using some modern Android design components(e.g. UI components designed by Ramotion, etc.). envirocar API contains lots of additional data, which can be used to visualize some interesting conclusions to the user(eg. User’s avg speed vs. global avg speed and many more). It is expected to add some meaningful visualizations and improve the UX of the enviroCar app. It is not only expected to work on the problems mentioned above, rather it is an open challenge. You can redesign the app wherever there is a possibility, which can improve the previous implementations.

Currently, old versions of libraries(RxJava, otto, retrofit etc) are used in the repository. Apart from the UI/UX part, it is also expected to update all the libraries used in the app to the latest versions.

Required Skills: Android software development, knowledge of modern development paradigms and frameworks for Android (RxJava, Dagger, ActiveAndroid, Otto, etc.). Good command of UI/UX development for Android. Familiarity with up to date Android components.

Expected Results: Improve the User Interface and User Experience of the enviroCar android application by redesigning the existing implementation and adding various visualization components using the data from the enviroCar API(e.g., from statistics endpoint). Update all the libraries used in the enviroCar android application. Documentation and implementation of tests for the above work.

Code Challenge: Currently, a single track card view in “My Tracks” tab contains very fewer details like duration, distance, track name, map view and occupy more space, which becomes very tedious to traverse through the whole tracks when there is a large number of tracks recorded. So it is expected to redesign the single track card view, which becomes more informative and at the same time occupying less space. Another issue is, uploaded tracks which are not downloaded completely are not much informative. So it is expected to redesign that card view such that uploaded tracks which are not downloaded completely become more informative.

Mentor: Arne de Wall (a.dewall@52north.org), Sai Krishna Chowrigari (chsaikrishna105@gmail.com)

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 (b.graeler@52north.org), Jan Schulte (j.schulte@52north.org), Simon Jirka (jirka@52north.org)

enviroCar 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 (b.graeler@52north.org), Arne de Wall (a.dewall@52north.org)

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

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

You can test your implementation with a demo wps supporting both versions (1.0.0 and 2.0.0) at http://geoprocessing.demo.52north.org:8080/wps/WebProcessingService

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

Mentor: Benjamin Pross (b.pross@52north.org)

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: r15 - 15 Mar 2019, ArneDeWall
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