Project Ideas for Google Summer of Code at 52\xB0North 2015


Main Page: GSoC2015

The is the ideas page for the Google Summer of Code 2015. 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\xB0North 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

Statistics for OGC Web services

Explanation: Maintainers of 52\xB0North SOS deployment currently do not know what the "most commen" requested procedures are and when people are requesting data for which area and time frame. Are users interested in the last week mostly, or do they request historical data as well? How large is the average response document? Which sensor stations get rarely any queries? How long do execute requests of a specific WPS process take on average?

To answer these questions, this GSoC project will develop a set-up using the ELK stack (though without the "L") to analyse SOS and WPS requests and responses to answer the questions above and capture "usage statistics", and to integrate these usage statistics somehow into the administrative backends of the services. The code of both projects must be adapted to forward the information of interest to an Elasticsearch server without logging all information. Evaluations must be done to ensure that the set-up does not slow down the regular request handling. Information that cannot be captured by "regular" HTTP statistics (e.g. procedures, time period, observed properties) are of highest interest, "regular" statistics such as response time could be captured as well.

This project requires students to have experience with Java.

Expected results: A working implementation of a component that can be integrated into the service's internal event bus which inserts relevant information into an Elasticsearch database, a corresponding Kibana application for analysis for the information.

Code challenge (updated!): Set-up the ELK stack "as is" (with Kibana 4) on a development computer, install the SOS and run some example queries. Create a Kibana Dashboard using the existing logging statements of the SOS, which are inserted into Elasticsearch using logstash (e.g. via file parsing and online tutorials or logback configuration). Add the demo data to the SOS (test client > "Batch" operation). Try to create some interesting data by sending multiple requests to the server over a period of time, e.g. using SoapUI (use the load testing feature) based on the example requests in the SOS's test client. If possible, create separate visualisations for the following SOS requests: GetCapabilities, GetObservation, DescribeSensor. Send screenshots of the dashboard, all configuration files, and if applicable the corresponding log files, to the mentors.

Community and Code License: Sensor Web community, Apache 2.0

Mentor: Simon Jirka (s.jirka@52north.org), DanielNuest

Progress status for WPS4R

Explanation: WPS4R is a collaboration platform for geostatistical analyses. It allows easy execution of R scripts as standardized WPS processes. For a good user experience, it is important that the WPS client can query the current process status to display a progress bar. Currently if an R process is executed, the status information will stay at 0 % after the process is started and then jump 100 % when the process is finished. This shall be improved by allowing communication of status from R to the WPS. This status can then be queried as part of the WPS Execute operation (schema for response).

A student in this project shall extend the WPS4R implementation with features to query a process status from R, for example from (R, system) environment variables or from a simple text file in the R workspace. This information must be provided from an R script and must be wrapped in documented R function calls, which script developers can add to their scripts. An investigation of the existing R function txtProgressBar should also be conducted.

Required skills: Java software development, R extension package development (at least one of these areas with good expertise).

Expected results: R script wrapping the process from script perspective, Java classes integrated in WPS4R to read the progress, integration tests and example algorithms (e.g. a loop through a data.frame), video that shows that status can be queried from WPS service interface.

Code Challenge: Install WPS4R locally from source and create an R script that (a) loops though a list of random vectors while (b) logging the current loop index and the value into a text file in the current working directory. The R script must have all annotations to run as an WPS4R process and return the content of the created text file as a process output. Send the created R script, a matching Execute request, and an exemplary response document to the mentors.

Community and Code License: Geoprocessing/Geostatistics, GPL v2

Mentor: Daniel N\xFCst (d.nuest@52north.org), NN

Next generation wps-js

Explanation: wps-js is a 52\xB0North 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\xFCst (d.nuest@52north.org)

Analysis of geospatial metadata

Explanation: Elasticsearch is a fast document database with very powerful indexing functionality to support searching on vast amounts of data and highly responsive user interfaces. In this projects, the aggregators feature will be used to create summary statistics for geospatial metadata that is stored within an Elasticsearch index to answer the following questions: How many sensors stations or datasets are measuring in a given area? What is the temporal coverage or all datasets for a given location? What organisations maintain observation networks for a given European country? ... and many more. The implementation comprises the actual scripted aggregators and a simple user interface (based on HTML5 and JavaScript on the client side, and Java or node.js on the server side) to execute and visualise pre-defined aggregations.

Expected results: Scripted aggregators for Elasticsearch for questions to be defined upon project start, HTML5/Javascript application to execute existing aggregators and visualize the results as interactive graphics.

Code challenge: Install Elasticsearch locally, harvest the contents (e.g. title and description) of metadata documents coming from this CSW (no need to install your own catalogue!). Then implement a scripted aggregator (see Elasticsearch documentation) for the data that counts the length records' description texts, and display the result of the aggregator in a HTML page. Send to the mentors a zip file with the request, aggregator script, the response the server creates, the HTML you use to display the result, and a screenshot of the HTML page.

Community and Code License: Metadata community, Apache 2.0

Mentor: Daniel N\xFCst (d.nuest@52north.org), Simon Jirka (s.jirka@52north.org)

sos4R for SOS 2.0

Explanation: sos4R is an R extension package to retrieve data from a standardized Sensor Observation Service (SOS) from within an R script. The R script developer only writes R functions and all the complex service requests and responses are completely hidden. Currently sos4R only supports SOS version 1.0.0 and this project will change that!

Students for this projects should have some experience with XML and XML Schemas and must have good experience in writing R.

Expected results: sos4R can encode requests and decode responses for the core profile of SOS 2.0, supporting both O&M 2.0 and WaterML 2.0 encodings for GetObservation responses. Both KVP and POX bindings are supported for core operations.

Code challenge: Implement a parsing function in R using this example document of a GetObservation response for SOS 2.0 based on the R package XML. The result shoud be an R data.frame with the values of the response document. The parsing function should be part of an otherwise empty R package and a testthat unit test which can be executed with devtools::test(). The test validates the function: "test that the number of values is equal to 10". A check on the package (i.e. execute R CMD check on the commandline using R version 3.x) should yield no errors and no warnings. Send to the mentors the minimal R package as a zip file and the output of the check as a txt file.

Community and Code License: Sensor web community, GPL v2

Mentor: Christian Autermann (c.autermann@52north.org), Daniel N\xFCst (d.nuest@52north)

enviroCar Linked Data

Explanation: Improve the way enviroCar data is served as Linked Data. Possible tasks are improvement of interlinking with other data sources, developing a SPARQL endpoint for enviroCar, and reviewing and applying existing semantic sensor web ontologies to the data. The student may also evaluate/ensure compliance with the GeoJSON specification and the application of wrappers that expose the data as standardized geo web services. Student expertise should include semantic web technologies and relevant frameworks such as Jena.

Expected results: Compliant and/or innovative ways to access the enviroCar data.

Community and Code License: Semantics, Sensor Web, Apache 2.0 License

Code challenge: Retrieve some of the enviroCar Linked Open Data through the enviroCar API and load the data into a triple store on your machine (e.g., Fuseki or Virtuoso). Write a SPARQL query to find all points where the speed exceeds 50km/h. Send an email to the mentor containing the dataset you used, the SPARQL query, and the result.

Mentor: Carsten Ke\xDFler ( carsten.kessler@hunter.cuny.edu)

Social driving stats

Explanation: The enviroCar project provides an open citizen science platform for sustainable mobility. Community members can collect and share their driving data. Users can also explore own tracks on their personal profile page and compare own statistics to those of others. However, sharing specific tracks or statistics is currently not possible. Hence, you will enhance enviroCar with sharing facilities and social media links by implementing a REST interface for creating and providing track visualisations (preview images, thumbnails) and statistics. Furthermore, in order to publish these information to a wide audience, you will also link enviroCar to popular social networks, such as Google Plus, Facebook or Twitter. Therefore, you will utilize the APIs of these platforms and integrate it within the user profile pages of http://envirocar.org.

Expected results: Dedicated sharing facilities for community members will be a great enhancement for the enviroCar plattform and ease the communication between the community and to external people using social networks.

Code challenge:
  • Create a REST resource (e.g. http://${envirocar-server-api}/tracks/${track-id}/preview ) providing a static dummy PNG image
  • Create a mockup of how the sharing of an enviroCar track coud look like in a Facebook timeline.
  • Create a mockup of how the sharing of user statistics could look like on Google Plus.
  • Write some example Tweets that enviroCar users might have created when talking about their data, tracks or their driving.
To complete the challenge, please send to the mentors (a) a zip file with the mockups and example tweets, and (b) a link to the GitHub commit(s) implementing the REST resource.

Community and Code License: enviroCar, AGPL v3 (server), MIT (JavaScript/Social Media connectors)

Mentors: Matthes Rieke (m.rieke@52north.org), Christoph Stasch (c.stasch@52north.org)

enviroCar light

Explanation: The enviroCar project provides an open citizen science platform for sustainable mobility. Community members can collect and share their driving data using an Android app. Currently, the start and end of a track needs to be defined manually by the user. You will improve the enviroCar app by automatically detecting the OBD2 adapter, that connects the android device to the car sensors, and then automatically starting to collect tracks. Required user interaction is reduced to a minimum. Once the connection is disconnected, the track needs to be finalized and uploaded automatically to the enviroCar server. You will also implement more sophisticated algorithms for automatically fusing disconnected tracks depending on a pre-defined time-interval and spatial location.

In order to test your developments, you need to be able to use a car and test your app on Androids devices. OBD adapters may be borrowed from 52\xB0North.

Expected results: Automatically collecting sensor data from a car once it is started, will greatly simplify the collection for enviroCar members and help to get more users on board.

Code challenges:

Community and Code License: enviroCar, GPL v3

To complete the challenge, please send to the mentors (a) a zip file with source code and apk of the Android app, and (b) a link to the track you created.

Mentors: Matthes Rieke (m.rieke@52north.org), Christoph Stasch (c.stasch@52north.org)

WPS-Ilwis Bridge

Explanation: The 52\xB0North WPS is a widespread implementation of the OGC Web Processing Service (WPS) specification. One of it's main features is the easy publication of analyses of geodata from different so called processing backends, such as R or GRASS. In this project the student will add another processing backend to the WPS based on the Ilwis NG GIS framework. Ilwis NG is written in C++ and there also is a Python scripting interface. The Python scripting interface is realized with SWIG, "a software development tool that connects programs written in C and C++ with a variety of high-level programming languages". In this project, the student will generate a Java binding for the Ilwis library using SWIG and demonstrate it's use as a backend for the 52\xB0North WPS.

Students for this projects must have experience with Java, further knowledge of C++ is a plus.

Expected results: Ilwis functionality can be easily exposed as a WPS process based on the 52\xB0North WPS. For demonstration purposes a both a vector (e.g. accepting a shape file as input and returning a shapefile as output which has the area of each input polygon as an additional value) and a raster algorithm (e.g. calculation of NDVI based on GeoTIFF raster input) must be implemented. The Java interface for Ilwis is a standalone project in the 52\xB0North GitHub repository and the libraries are available in the 52\xB0North Maven repository.

Code challenge: Locally build the Java module based on this tutorial (this or this might also help). Locally install the 52\xB0North WPS based on the source code (current development branch) and create a Java process that computes the factorial of a given number based on the provided class. To complete the challenge, send the mentors a zip file with the Java process and the Java module created by you.

Community and Code License: Processing community, GPL v2

Mentor: Benjamin Pross (b.pross@52north.org), Martin Schouwenburg (m.l.schouwenburg@utwente.nl)

Geoservices REST-API for SOS

Explanation: The 52\xB0North 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 (http://www.esri.com/industries/landing-pages/geoservices/geoservices). The task in this project is to develop a new binding for the 52\xB0North 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\xB0North SOS server 4.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\xB0North 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 2015.

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\xB0North Sensor Web/SWE mailing list.

Community and Code License: Sensor Web, GPL v2

Mentor: Carsten Hollmann (c.hollmann@52north.org) and Simon Jirka (jirka@52north.org)

NetCDF backend for SOS

Explanation: The 52\xB0North 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, NetCDF 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, a new approach is needed using file.based data stores as an alternative to databases. In the past, a first prototypical project was completed. In this project, an adapter to read NetCDF files was developed (http://blog.52north.org/2013/10/16/using-netcdf-files-as-an-sos-data-source/). However, the results of this project are focused on NetCDF and are not integrated into the regular SOS development line.

This GSoC project comprises the following tasks:
  • analyze the existing implementation
  • develop an abstraction layer (data access object) to support file-based data storage in the 52\xB0North SOS (with the option to add further data formats beyond NetCDF in the future, e.g. CSV)
  • add NetCDF support to the latest 52\xB0Nort SOS development line, relying on the abstraction layer you will develop
  • enhance the web-based administration interface of the 52\xB0North SOS so that a user can manage/configure the files 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\xB0North SOS so that the SOS can serve content stored in files (e.g. NetCDF files). Furthermore we expect an enhanced administration interface of the SOS to configure and manage the files the SOS shall use as input.

Code challenge: Build the current version of the 52N NetCDF SOS and deploy it on your computer. Please send the GetCapabilities response of your server after successful installation to the mentors of this project. In case of any questions, please subscribe to the 52\xB0North Sensor Web/SWE mailing list.

Community and Code License: Sensor Web, GPL v2

Mentor: Carsten Hollmann (c.hollmann@52north.org) and Simon Jirka (jirka@52north.org)

OPeNDAP backend for SOS

Explanation: The 52\xB0North 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\xB0North 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\xB0North SOS
  • add OPeNDAP support to the latest 52\xB0Nort SOS development line relying on the abstraction layer you will develop
  • enhance the web-based administration interface of the 52\xB0North 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\xB0North 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 nomads.ncdc.noaa.gov OPeNDAP server. Send the created GetObservationDAO class file to the mentors of this project. In case of any questions, please subscribe to the 52\xB0North Sensor Web/SWE mailing list.

Community and Code License: Sensor Web, GPL v2

Mentor: Carsten Hollmann (c.hollmann@52north.org) and Simon Jirka (jirka@52north.org)

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 = "http://dd.eionet.europa.eu/vocabulary/aq/pollutant/1"
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 (m.rieke@52north.org) and Simon Jirka (jirka@52north.org)

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 (h.bredel@52north.org), Kai-Minh NGO, and Simon Jirka (jirka@52north.org)

Cross-catalog UI for Linked Data

Explanation: The context of this GSoC project is the development of a research data infrastructure for scientists working in the field of climate change and sustainable land management. A central part of this distributed infrastruture are catalogues (OGC CSW) that allow to search for geospatial datasets and services based on metadata (ISO 19115 and 19139) . For the scientific data the representation of the data lineage (history) is vital. Therefore, the aim of this project is to extend the lineage capabilities of two catalogue implementations used in the infrastructure.

The first catalogue is GeoNetwork, which provides an RDF interface for published metadata (example 1, example 2). This RDF interface does not provide lineage information for datasets, although this information is stored in the GeoNetwork database (see here > switch to XML mode and look for the tag \x93gmd:lineage\x94). Therefore, your first task is to extend the existing RDF interface to provide the lineage information as Linked Data.

Typically, complex queries are performed on several catalogues by using the Linked Data paradigm. The second catalogue implementation, the !GLUES catalogue, also provides metadata for other geospatial datasets, but does not provide an RDF interface. Therefore the CSWLodEnabler is used to harvest this catalogue and to map the provided metadata to Linked Data (RDF triples). A Virtuoso server is than used to publish created RDF data and to provide a RDF interface like GeoNetwork\x92s RDF interface, see live demo.

Your second task is to implement a user interface that enables users to perform complex queries on both catalogues, GeoNetwork and GLUES catalogue. Details regarding the user interface structure and the SPARQL queries will be provided via mail.

Expected results: Implement the modified RDF interface for GeoNetwork and a user interface to query on several catalogues, this means:
  1. Extended interface: Enabling the GeoNetwork RDF interface for lineage
  2. User interface with a) lineage querying and b) spatial queries (global/regional) (queries will be provided via mail)

Code challenge: Implement a user interface (HTML and Javascript), which enables users to query a search term on two catalogues. The user interface should contain an input for the search term, a button to send the request to two catalogues and a result section, showing the integrated responses, i.e. the responses from both servers are shown in a unified list (like Google) with a color displaying the catalog where the item came from. A request example to query \x84observation\x93 is: http://apps1.glues.geo.tu-dresden.de:8080/geonetwork/srv/eng/rdf.search?any=observation Use a local version of the geonetwork and the following one: http://apps1.glues.geo.tu-dresden.de:8080/geonetwork. Send source code and screenshot of local geonetwork.

Community and Code License: Metadata, Apache 2.0

Mentors: Stephan M\xE4s (Stephan.Maes@tu-dresden.de), Christin Henzen (Christin.Henzen@tu-dresden.de)

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\x92s metadata, software requirements to execute the algorithm are stored (@see tags platform and runtime component).

The Appstore\x92s sandbox enables to test and execute published algorithms before downloading and embedding them in their own software environments. 52\xB0North 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\x92s 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\x92s 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\x92s 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\xB0North 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 (Christin.Henzen@tu-dresden.de), Johannes Brauner (Johannes.Brauner@tu-dresden.de)

Linked data interface for geooperators

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). Information on published algorithm source code, e.g. algorithm description, author or keywords, is stored as respective metadata. In the algorithm's metadata, geooperators used to implement the algorithm are described as specific metadata keywords. Geooperators provide building blocks for the geospatial algorithms, and are semantically described. Beside semantic metadata, a geooperator description contains links to similar geooperators to enable an implementation independent creation of workflows and thus enhance interoperability for the developed algorithms. Furthermore, the geooperator descriptions provide links to further geooperators that are often used in the same context. Your task is to implement a Geoprocessing Appstore component for managing and querying (linked) geooperators. First, you should implement a user interface that enables users to prepare a geooperator description, link to existing geooperators and store the geooperator information in a Linked Data format (http://geoprocessing.geo.tu-dresden.de/data/geooperator_thesaurus_xml.rdf). Furthermore, the component should realize a Linked Data interface to query published geooperators (in !RDF format) by name or query related geooperators and a user interface that enables users to perform queries on this interface.

Expected results: Implement a query interface for geooperators and a user interface for managing geooperators based on the existing Appstore implementation (demo, code).
  1. Interface to link to geooperators
  2. User interface to manage and query on geooperators

Code challenge: Implement a user interface (HTML and JavaScript), which enables users to query information on a geooperator. The user interface should contain an input for the geooperator name, a button to send a request and a result section, showing information on the queried geooperator and similar geooperators (e.g. name, scope note, categories). Use the RDF interface provided in here, with the following encoding: geooperator name -> rdf:about and skos:prefLabel in rdf:Description, related geooperators -> skos:narrowMatch and skos:broadMatch, categories -> skos:relatedMatch, scope note -> skos:scopeNote.

Community and Code License: Geoprocessing, Apache 2.0 for the Appstore (?), Creative Commons Attribution-ShareAlike 4.0 International License for the Geooperator description.

Mentors: Johannes Brauner (Johannes.Brauner@tu-dresden.de), Christin Henzen (Christin.Henzen@tu-dresden.de)

Terrain Model Generation and Analysis

Explanation: The 52\xB0North 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\xB0North Triturus library already provides a lot of Java-implementions 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 RESTful).
  • Implement missing flooding analysis function (in the 52\xB0North 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).
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\xB0North 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\xB0North terrainServer 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\xB0North 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\xB0North 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\xB0North 3D mailing list.

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

Mentor: Benno Schmidt (b.schmidt@52north.org), Andreas Wytzisk

Web-based 3D Visualizations

Explanation: World maps and interactive globes always seem to be popular. Regardless, there is a demand for innovative World visualizations allowing experimental communication of thematic data, e.g. to activate young Web users. Thus, suitable interactive 3D World visualizations presenting thematic information layers shall be implemented.

This GSoC project comprises of the following tasks:
  • Realize generic X3DOM-based globe visualization for World country data (image texture and shape import) as Java Servlet.
  • Design and implement a Web-client incl. interactive information query facilities (DOM/JavaScript).
  • Implement Earth surface deformations ("potato-like" geometry) dependent on thematic attribute values using the existing 52\xB0North Triturus library with its terrain modelling tools (VgElevationGrid interface).
This project requires students to have experience with Java, Internet technologies (HTML, JavaScript, XML, Servlets) and basic knowledge in the field of 3D computer graphics (e.g., indexed face set construction) and geovisualization.

Code challenge: Show an X3DOM-based World/globe representation with image texture inside your Web-browser, let the user click at a position on the globe and display the corresponding lat/lon coordinates using HTML elements. Further on, add a button to the HTML page that allows to toggle between two image textures. Send the source code to the mentors of this project.

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

Mentor: Benno Schmidt (b.schmidt@52north.org), NN

3D Connection Maps

Explanation: Tools to set-up thematic maps showing connections or dependencies between different spatial features (e.g., good imports/exports of the World's countries, flight connections between airports, or chat contacts between Internet users) are hard to find. Thus, this project addresses the realization of an application that allows to set up connection maps based on X3D (resp. X3DOM for the Web) in 3D space based on 52\xB0North Triturus. From the algebraic perspective, this project deals with graphs (V,E) consisting of a set of spatially referenced vertices (V) and a set of directed and weighted edges (E) representing the connections. Since a network structure might be rather complex, an interactive vertex (feature) selection tool should be available to support data exploration processes.

This GSoC project comprises of the following tasks:
  • Implement Java-components to allow XML-based data import.
  • Design and implement Java-code to generate (aesthetic) X3D-based scenes using various interactive presentation techniques (arrows, cocoons etc.) as well as KML descriptions (e.g., to be used in Google Earth).
  • Design and implement an XML-based interface to specify cartographic scene design (object colors, line widths, curvature parameters etc.).
  • Provide demo application.
This project requires students to have experience with Java, X3D (or VRML) and basic knowledge in the field of 3D computer graphics (basic shape primitives) and geovisualization.

Expected results: The produced code will be integrated into the new 52\xB0North "WorldVis" module, which will be based on the existing 52\xB0North Triturus Java-library. At the end of the project, a ready-to-run application with a defined input interface will be available.

Code challenge: Implement a simple reader to access files in Pajek NET format (see http://gephi.github.io/users/supported-graph-formats/pajek-net-format/) in Java and implement a simple X3DOM scene showing the graph's vertices and edges. Please send the HTML (X3DOM) scene and the Java source code to the mentors of this project.

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

Mentor: Benno Schmidt (b.schmidt@52north.org), NN

OPeNDAP for SOS Importer

Explanation: Many organisations serve their NetCDF via Thredds or other OPeNDAP server. It would be helpful importing manually/automatically SOS with new added NetCDF files served by the OPeNDAP server. Maybe even give an option to define a query for importing only specific datasets based on filters. A interface for selecting and filtering the datasets would be even more user-friendly.

Within this project "!OPeNDAP Client Import Module for the 52\xB0North SOS Importer", you will need to understand the SOS Importer and OPeNDAP API. This is a project with medium to high complexity. To work on this project you will need experience with Java development.

Expected results: The result will be the extension of the 52\xB0North SOS Importer to support OPeNDAP next to the already supported CSV files as datasource.

Code challenge:

#1 Get in touch with the software
  1. Build the current version of the 52N SOS Importer,
  2. get the current version of the 52N SOS, and
  3. deploy both software on your computer.
  4. Select a CSV file with the example data for the SOS Importer Homepage and
  5. import the data into the 52\xB0North SOS via the 52\xB0North SOS importer.
  6. Please send
    1. the GetCapabilities response of your server after successful importing,
    2. the created import configuration file,
    3. the GetObservation request and response to retrieve the value of Krypton on 15.09.1984 around 22:45
      to the mentors of this project.
#2 Do sample coding
  1. Fork the 52N SOS Importer project into your own github account.
  2. Add new branch "feature/gsco-2015-code-challenge-2".
  3. In this branch extend the 52N SOS Importer Core module with a new option for step one.
    This option should be "OPeNDAP" and display useful input fields in the GUI, so the user can provide all information that is needed to access the OPeNDAP server and retrieve the data. The German translation can just be the English terms (translation will be performed by the mentors if you can not write German). If possible, provide tooltips for each input field.
  4. When finished provide your results in a pull request on github to the branch "develop" of repository "EHJ-52n/sos-importer".

HELP In case of any questions, please subscribe to the 52\xB0North Sensor Web/SWE mailing list.

Community and Code License: Sensor Web, GPL v2

Mentor: Eike H. J\xFCrrens (e.h.juerrens@52north.org) and Simon Jirka (jirka@52north.org)

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>

(NEW) 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>

Coarse ideas and general goals

  • use ideas from upcoming research projects (hopefully starting mid-2015) -- DanielNuest - 2014-10-02
  • 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
  • see note from last years review: GSoC2014Review
  • 52N-Days brainstorming
    • IOs version of enviroCar app
    • enviroCar website
    • PhoneGap f\xFCr JS client
    • SOS.js for SOS 2.0 based on ows.js
    • ArcGIS SOE -- MatthesRieke