You are here: Wiki>Projects Web>GSoC2016>GSoC2016ProjectIdeas (15 Mar 2016, ChristophStasch)Edit Attach

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

Main Page: GSoC2016

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.

In order to derive higher-level information products, the data needs to be processed, e.g. by using segmentation algorithms. In former times, the workflow included downloading the data, pre-processing it by selecting the spatial and/or temporal extent, and then running the actual segmentation process. The idea of rich data interfaces is that these processing facillities for deriving new information products are directly provided with the data in order to avoid downloading large raw datasets.

The aim of this project is to develop a Web Processing Service for deriving higher level information products from Copernicus data, e.g. providing segmentation algorithms.

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

Expected results: Web Processing Service that provides a Rich Data Interface for Copernicus data. The WPS should offer at least two different processes, e.g. segmentation process and a process for deriving an index.

Code Challenge: Checkout the sources of the latest version of the 52N WPS and implement an algorithm 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: Benjamin Pross (, Christian Autermann (

Usability improvements for smle

Explanation: smle is a new development of 52°North based on TypeScript and Angular 2 that enables web based editing of SensorML descriptions. As the project has just started, the actual scope of this project is currently quite wide and subject to change. The coarse idea is to improve the usability of the editor in some points. But, depending on the state of the project in the summer, it could also include general development of new features.

Possible things that could be done:
  • Selecting the bounding box or position of a physical process from a map
  • Persisting the contact information of the current editor in the browser's local storage to reduce the effort when editing multiple sensor descriptions
  • Selecting components of aggregating processes from a list of processes retrieved from a sensor registry
  • User interface for creating various GML geometry types
  • Anything else that makes the the editor more usable
  • Development of various backends to persist descriptions (e.g. SIR, SOR, Open Sensor Search, SOS, etc.)
Experience in the following technologies is recommended: Expected results:
  • SensorML editor with improved usability as well as additional functionality (will be dynamically determined during the project)
Code challenge:
  • Fork & clone the project from GitHub:
  • Look at the package.json, build the project and open it in a web browser
  • Build a small angular component that enables the editing of an address
  • Send the mentors the link to your fork on GitHub
Community and Code License: Sensor Web, ASL 2.0

Mentors: Christian Autermann (, Simon Jirka (

Scalability and reproducible research with iceland

Explanation: This project will make iceland, 52°North's framework for implementations of OGC web services, and other software implementations ready to be used in conjuction with Docker. This serves two purposes. First, new users can easily test out service and client implementations by simply running the Docker image locally, and power users can use the Dockerfiles to easily deploy multiple instances of services in cloud environments. Second, scientific analyses based on web services can be made independent from the online service without changing the analysis implementation: a scientist simply starts a local server instance and clones all required contents from the services into the local one. The local Docker image can then be archived and run at any point in the future to reproduce the analysis without relying on the online service to be available. The advantages of this approach are (a) it saves the time to adjust the analysis code to use something other than the service API, and (b) no adjustments to the code means a lower risk of introducing anything to the code that might change the analysis result.

The project comprises the following tasks:

  • Extend iceland so that the initial configuration settings can be submitted via an HTTP API (or equivalent mechanism)
  • Implement a "SOS copy tool" for the 52°North SOS that transfers selected observations from one instance to the other via the transactional interface
    • Clone a SOS completely by iterating through all observation ID. This might require a special endpoint to get access to all observation IDs.
    • Clone a SOS partially: The data transfer must support the following filters to transfer subsets of data: offering, time span.
    • The tool is implemented in Java based on the implementation of encoders and decoders from the SOS
    • The tool must be executable from the command line, so that it can be included in a Dockerfile, using docopt
    • This tool should run standalone, but could also become part of the SOS adminstrative backend: after installation of the SOS, an admin logs in to the admin interface, then fills out a form with details of another 52°North SOS instance, which is then harvested for data
  • [Optional] Change the configuration implementation of RESTful Sensor Web API to iceland
  • [Optional] Adjust configuration mechanism for JavaScript client, if necessary, to allow configuration from the Dockerfile (see above)
  • Create Dockerfiles and docker-compose configurations for the latest release as well as current development builds of the following implementations (with decreasing priority):
    • SOS (one small, one with nginx and SOS.js via https)
    • RESTful Sensor Web API
    • JavaScriptClient
    • [Optional] WPS (one small, one with R and/or Grass containers, another one with wps-js in extra container)
    • [Optional] smle
    • [Optional] Supervisor (requires also changing the configuration mechanism to iceland)
  • [Optional] transactional deployment of WPS processes at Docker image build time
The student should have programming experience in Java and know Linux. Ideally experiences in Docker and scripting with Bash exist as well.

Expected results:
  • Dockerfiles for SOS, RESTful Sensor Web API and JavaScript client for both the respective release and development versions are available under the 52°North account on Docker Hub.
  • A docker-compose configuration for the whole stack (all three components) and according documentation are published as a repository within the 52°North Organisation on GitHub.
  • Running an SOS server locally in a container and transferring data from a remote SOS to the local one can be done with two command line calls (one to start the container, one to transfer data).
Code challenge: This challenge comprises two seperate tasks to demonstrate both an understanding of Docker as well as coding skills:

  1. Dockerized SOS
    • Fork the SOS repository
    • Create a docker-compose configuration that installs the latest SOS from GitHub and runs it on top of a Postgres database (which is in a seperate container)
    • Add that configuration and Dockerfile to your fork
    • Create an automated build on Docker Hub for your SOS Dockerfile
  2. Add a RESTful endpoint in the SOS that saves a submitted JSON document into the configuration directory. The endpoint shall only be accessible when the SOS is not configured yet and return an appropriate HTTP error when the SOS is configured.
Send an email to the mentors containing the link to the build on Docker Hub and the commits on GitHub implementing the second part.

Community and Code License: Sensor Web, Geoprocessing, ASL 2.0

Mentors: Daniel Nüst

Next generation wps-js

Explanation: wps-js is a 52°North project for creating form-based user interfaces based on a WPS process description. In this project, wps-js will be updated to no longer use OpenLayers as the base library for encoding and decoding of XML documents, but to use JSONIX. The WPS client code within wps-js shall be moved to the ows.js project at OSGeo and only the form creation code remains with wps-js. As far as possible, new features from the wps-js project backlog (see GitHub issues) shall be implemented, too.

Expected results: ows.js extended with WPS client for WPS 1.0.0 and 2.0.0 using JSONIX; wps-js form generation based on new WPS client.

Code challenge: Create an HTML form with one field for an URL. On asynchronous form submission, a WPS GetCapabilities request using POX is sent to the defined URL and the response is parsed using JSONIX and the name of the WPS is displayed in an HTML DIV element within the same page. Send a zip file with the HTML and JavaScript you created to the mentors.

Community and Code License: Processing community, Apache 2.0

Mentors: Benjamin Pross (, Daniel Nüst (

Visual Analytics of enviroCar tracks


The analysis functionality provided on the profile page of registered enviroCar users lists all tracks of a user and provides basic visual analytics facilities of single tracks, e.g. analyzing the positions in an interactive map and analyzing parameters like speed or fuel consumption in a time series chart that is linked to the interactive map. The current page is implemented in php.

The goal of this project is to migrate the analytics page to JavaScript (using angular.js) and to add additional visual analytics facilities. Therefore, a flexible architecture should be implemented that allows to easily add additional analysis tools on the analytics page.

Expected results:

The expected results are:
  • a standalone track details page coded in JavaScript (using angular.js) that may serve as a starting point for a next gen version of the enviroCar website
  • the new page should enable users to explore and analyse their tracks in a flexible manner (e.g. length, date, duration, map view, ...)
Code challenge:
  • create a view for a single track, including track details (date and lentgh, distance travelled, mean property values) using angular.js. The view should also have a map representation of the track using leaflet.
  • implement R script that performs a simple analysis of a single enviroCar track
  • include a Web interface to the created view that allows to pass parameters to the R script, execute the script and explore the results using JavaScript (e.g. using the OpenCPU package in R)

Complete the challenge, please send to the mentors (a) a zip file with the Javascript files, the R script and any additional resources required and b) a link to the Web interface that allows to pass parameters and execute the R script or provide a link to a repository where the required items can be found.

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

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

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 (

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

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 (see code challenge). 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 Sensor Web 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.

Code challenge 1:
  • Get acquainted with the Sensor Web REST API.
  • Checkout the JavaScript Client to access timeseries 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 ( and Simon Jirka (

Geoprocessing sandbox

Explanation: The Geoprocessing Appstore is a Web platform that enables users to publish, search and download implementations of geospatial algorithms (live demo, source code; project is based on the Open Source !ESRI geoportal server). Algorithm code and description of algorithm (metadata XML) are packed as Moving Code packages (ZIP file; use live demo link to download a package). In the algorithm’s metadata, software requirements to execute the algorithm are stored (@see tags platform and runtime component).

The Appstore’s sandbox enables to test and execute published algorithms before downloading and embedding them in their own software environments. 52°North WPS and wps-js provide the basis for the sandbox. Currently, for each published algorithm a link to the sandbox is provided in the Appstore user interface. Software requirements that are described in the algorithm’s metadata description are not used for the sandbox. Goal of this GSoC project is to implement a Geoprocessing Appstore component, which detects installed software on the Appstore machine, e.g. Java or Python, and matches them to parsed software requirements of the algorithm’s metadata description. This matching should be used to either allow users to execute the algorithm code in the sandbox (all required software is installed) or not (not all software is installed), e.g. showing sandbox link or not.

Expected results: Extend the current sandbox implementation:
  1. Implement new component to detect installed software on the Geoprocessing Appstore machine
  2. Implement new logic to compare detected software with parsed requirements of the algorithm’s metadata
  3. Modified user interface that enables or disables navigation to sandbox based on comparison
Code challenge: Create a Java class that detects the Java and Python version that are installed on the local machine and add them to a list of installed software within a Java class (create your own Java class hierarchy). Publish this detection as an algorithm in the 52°North WPS, which returns the version information for either Java or Python depending on an input parameter "language". Send to the mentors the Java algorithm, the execute request and an exemplary execute response.

Community and Code License: Geoprocessing, Apache 2.0

Mentors: Christin Henzen (, Benjamin Pross (

Terrain Model Generation and Analysis

Explanation: The 52°North terrainServer offers Web-based services providing perspective terrain views as well as interactive 3D scenes (e.g., X3D-encoded). Terrain model generation and analysis is limited to just a few functions yet, though the underlying 52°North Triturus library already provides a lot of Java-implementations to perform such tasks.

There are many practical scenarios, where it would be desirable to have Web-based access to analysis tools (e.g., difference surfaces, mass calculations, inclination analysis, just to mention some) and to model generation functions.

This GSoC project shall supply the basic service infrastructure to set-up model generation and analysis services. Selected tools will be implemented prototypically. The project comprises of the following tasks:
  • Design and implement a user-specific model access concept (including server-side model management) and multi-model support for the 52N terrainServer extension.
  • Design and specify proper terrain service interfaces (HTTP-Post or maybe RESTful).
  • Implement missing flooding analysis function (in the 52°North Triturus library) needed for the demo application. (Note that grid generation functions are already implemented.)
  • Design and implement a demo Web-client (HTML5/JavaScript) and test the application with sample point data (XYZ) and a browser/based X3DOM visualization (WebGL/HTML5).
Note that this project rather focuses on the task of personalized Web-enablement than on algorithmic issues, since most of the needed algorithms already are available in the 52°North Triturus library.

This project requires students to have experience with Java and Internet technologies (HTML, JavaScript, XML, Servlets) and basic knowledge about digital terrain modelling.

Expected results: The result will be an extension of the 52°North terrainServer module (or a new 52°North module). The demo application set-up by the student will give hints to judge the suitability of the approach (proof of concept). Since the number of terrain generation, analysis, and editing functions seems inexhaustable, this prototype application will open the 52°North terrainServer for several interesting use cases (surveying, civil engineering, sensor data interpolation etc.). Here, a terrain's z-values might refer to elevation data or other quantitative values, e.g. temperature data, precipation etc. Thus, in the future more relevant functions could be added to the module, e.g. feature extraction and change detection algorithms, flooding calculation tools, TIN-editing tools etc.

Code challenge: Build the current version of the 52°North terrainServer and deploy it on your computer. Please send a GetElevation request (HTTP-URL) and the corresponding XML-encoded response of your server after successful installation to the mentors of this project. After that get to know the 52N terrainServer source code and add an operation, that determines the number of point data measurements (XYZ) pasted from a HTML form (textarea-element) to your extended terrainServer. Send your source code to the mentors.

In case of any questions, please subscribe to the 52°North 3D mailing list.

Community and Code License: 3D community, Apache 2.0 license

Mentor: Benno Schmidt (, Christian Danowski (

Draft Ideas

Dynamic Visualisation of Mobile Objects in the JavaScript SOS Client

Explanation: The 52°North JavaScript SOS Client was originally developed for visualizing data measured by stationary sensors. However, in the user community of 52°North Sensor Web components there are more and more use cases which are based on mobile sensors or objects. Thus, a different type of visualization is needed. Currently there are ongoing developments that will enable the client to visualize tracks and the measurements that were taken along these tracks. However, as a next step, it would be useful to have an option to visualise the movement of sensors (or other objects) on a map. The idea is to develop a new view that offers a time slider for selecting a certain point in time. This slider would be coupled with a map view so that the sensor/object locations for the selected point in time are shown.

Expected results: New view for the 52°North JavaScript SOS Client ( that includes a time slider and allows to visualise the time-dependent position of tracked objects.

Code challenge: TBD

Community and Code License: Sensor Web community, Apache 2.0 license

Mentors: Jan Schulte (, Simon Jirka (

---++ SEO for OGC Web Services

Explanation: The discovery of OGC-based Web services is still a topic which needs improvements. While Catalogues for spatial data infrastructures exist, the discovery via seach engines such as Google is often not systematically supported. Thus, the idea is to enhance the 52°North web service implementations with a langing page em bedding meta-tags, semantic descriptions (e.g. or Hydra based descriptions encoded in JSON-LD).

Expected results: Additional module that can be used by the 52°North Web service implementations to provide a landing page offering meta-tags, semantic descriptions for a web service instance.

Code challenge: TBD

Community and Code License: TBD

Mentors: Christoph Stasch (, N.N.

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

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: r24 - 15 Mar 2016, ChristophStasch
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