Google Summer of Code Project Ideas 2013

Main Page: GSoC2013

The is the ideas page for the Google Summer of Code 2013. If you are an interested student please don't hesitate to contact mentors directly or discuss your own ideas on the mailing lists.

WPS 2.0 Implementation

Explanation: The Open Geospatial Consortium (OGC) has established a standards working group (SWG) to work on the version 2.0 Web Processing Service (WPS) specification. This has been going on for a while, but in the last months there has been some good progress. As some points are still open for discussion, and because OGC standards have been critized in the past years that they are "hard/impossible to implement" or that they do not cover realistic scenarios, we want a student to help to improve the standard that is developed by providing an implementation of the latest available public draft of the specification based on the current 52°North WPS 1.0 codebase, especially the "WPS-G" branch by Spacebel. With the experience from the implementation and demonstrations to be developed by the student, the SWG can get valuable inputs for shaping the next WPS specification.

If the student makes good progress, the implementation of CITE tests would be a possible extension of the work. In any case, the student will get to know a stable and well known web service implementation and how standards are made in an international organisation.

The potential student should have experience in web service implementation with Java and good communication skills. Agile software development experience and the ability to develop quick prototypes for usecases from the geospatial domain.

Expected results: A WPS 2.0 implementation (based on the public RFC version) based on the 52°North Processing Server codebase. This work could act as a base for a potential reference implementation of the WPS 2.0 specification.

Community and Code License: Geoprocessing, GPL 2.0

Mentors: Benjamin Pross (b.pross@52north.org), Matthias Müller (Matthias_Mueller@tu-dresden.de)

Trajectories in R

Explanation: The current handling of trajectory data in R is scattered, partial, and strongly linked to particular domains (mainly ecology); generic data structures and methods (see SpatioTemporal task view on CRAN). This GSoC project will implement and/or improve generic classes, methods and tools for handling and analyzing large-scale trajectory data with R.

Expected results: Classes and methods for handling trajectories in R, building on the classes for handling spatio-temporal data in R in package spacetime. Low-level manipulation will involve selection (by individual, by trip), aggregation (to a lower spatial and/or temporal resolution), sampling, simple (linear) interpolation and visualisation (by animation and by conditioning plots). Analysis methods will include computation of attributes (speed, direction); computing distances between trajectories; simple statistical methods for interpolation such as biased random walk. Code should be integrated in spacetime or depend on it; package should be ready for submission to CRAN.

Community and Code License: Geostatistics and Geoprocessing, GPL 2.0

Mentors: Edzer Pebesma (pebesma@52north.org), Daniel Nüst (d.nuest@52north.org)

Package Builder Service

Explanation: The comprehensive R archive network (CRAN) shares the load of providing packages by mirroring a directory tree. It communicates with package maintainers by email when maintenance is required. The R-Forge platform has become very popular because in addition to providing source code management (svn) it also provides a service to build the most recent version of the package. R-Forge has suffered under it's popularity and the build system has recently been down for longer periods. In this project we want to see if we can help out by creating a shared, distributed mechanism for package building based on the web processing service interface. The students tasks are:

  • Describe a simple WPS profile for a "package compile" process (keeping in mind things like architecture, i.e. building for Windows, Linux, ...) and challenges such as building against CRAN versus building against all most recent versions on R-Forge)
  • Implement that process based on WPS4R and existing R packages, see for example R-Forge Tools
  • Develop extensions to R-Forge so that a package compilation can be outsourced to WPSs
  • Create an easy to install, platform-independent and pre-configured "R Compiler Server" along with documentation so that anybody can set it up and contribute.
Potential students should have experience in both R and Java development, be familiar with external library dependencies (gdal, geos, etc) and be a good communicator to facilitate the potential of interaction with the huge R community.

Expected results: Complete the above listed tasks in strong collaboration with the R community.

Community and Code License: Geostatistics and Geoprocessing, GPL 2.0

Mentors: NN, Daniel Nüst (d.nuest@52north.org)

Sensor Data Access for Rasdaman

Explanation: Rasdaman is a domain-independent array DBMS, and its petascope component provides a variety of standardised interfaces (such as OGC WCS(-T) and WCPS) to insert and retrieve geospatial data. This project should connect Rasdaman as a data storage backend to the 52°North Sensor Observation Service (SOS) implementation by adding Rasdaman as a data source in the 52°North SOS. This could be done at different levels: using SQL/Hibernate, a plain Java implementation (based on the Java API), or by implementing a generic JDBC driver. These drivers specify common interfaces for accessing relational databases, and many applications have plugins for connecting to databases via JDBC/ODBC drivers - so this would be a great contribution to the rasdaman community, too. At the beginning of the project a prospective student should test and evaluate these possibilities.

Further work would then include and implementation of the SOS-T interface for data insertion. The implementation shall be tested with a large climatology database such as HadCRUT, GHCN or ECA&D. This project is challenging but great at the same time because you get two know two Open Source communities within just one summer!

Some further reading:

Expected results: 52°North SOS Rasdaman "data access objects" (internal data source represenation of SOS), Rasdaman Hibernate mappings for 52°North SOS, integration of the 52°North SOS into petascope (user guide, testing, and documentation), users can query data from rasdaman using the SOS interface (tested with the Sensor Web client and sos4R).

Community and Code License: Geoprocessing, GPL 2.0

Mentors: Daniel Nüst (d.nuest@52north.org), Dimitar Misev (d.misev@jacobs-university.de)

52°North Processing Server Admin Interface

Explanation: The current admin interface for the 52°North WPS implementation is heavily coupled with the underlying functionality and modules. This makes it hard to extend the functionality and to package smaller functional packages of the service since the admin interface directly requires many modules. Therefore the admin interface must be transferred from the current HTML/JSP approach to a modern and flexible web application framework. The admin interface should be visually appealing and technologically flexible, e.g. use RESTful interface to configure the server instead of submitting plain old HTML forms.

A potential student must be familiar with Java and web client development, preferably with a framework such as Spring, and be able to work in a larger development team. Experience with agile software development and the ability to produce intuitive and attractive user interfaces would be a great plus. This is a challenging project which will catch a lot of interest from the user community.

Expected results: Modular web client interface that supports the current use cases (managing algorithm repositories, uploading R scripts, uploading moving code packages). The module specific function, such as R script management, must be moved out of the webapp module to the R extension module.

Community and Code License: Geoprocessing, GPL 2.0

Mentors: Benjamin Pross (b.pross@52north.org), Daniel Nüst (d.nuest@52north.org)

R Web Processes for Streaming Data

Explanation: WPS4R is an extension of the 52°North Processing Server which bridges between the domain of scientists doing analysis in the R software environment for statistical computing and graphics, and the geospatial web service domain.
The student will work on extending the existing implementation with much desired functionality for streaming sensor data, i.e. a continued analysis of measurements by sensors, with a use case of statistical quality assurance and quality control (QA/QC). The student will work based on the existing software implementation in both Java and R using real sensor data from the United Sates Geological Survey (USGS).

A potential student should be familiar with Java and/or R development and be able to work in a team of developers. Experience with agile software development is also good, as is some experience with geospatial data.

Expected results: Conceptual design and implementation of a framework to deploy qa/qc algorithms for streaming sensor data on a webservie.

Community and Code License: Geoprocessing, GPL 2.0

Mentors: Jordan Read (jread@usgs.gov), Matthias Hinz (m.hinz@52north.org)

Mobile Sensor Web Client

Explanation: Sensor Web services make sensor data and events accessible to many end users, though currently it is mostly specialists and domain experts utilizing the generic tools. To broaden the userbase we want to develop a mobile sensor web client based on current web technologies (HTML5). The student should extend the existing functionality of the RESTful backend the browser Sensor Web Client to display server-side rendered of large time series plots in an easy to use interface. The RESTful backend should be used to leave the XML requests and response handling to a powerful server. For starters, frameworks such as gwtmobile/mgwt and Apache Cordova should be evaluated. As an additional task, the student could evaluate the direct access of sensor data from an Sensor Observation Service with JSON response encoding and client-side rendering.

The student should have experience with programming for mobile devices, optimally with one of the mentioned frameworks. Also, for the server component, Java experience is useful. This project is quite well adaptable to the students capabilities.

Expected results: Easy to use web client to access sensor data on many different mobile devices supporting the current 52°North sensor web components.

Community and Code License: Sensor Web, Apache 2.0/GPL 2.0

Mentors: Jan Schulte (j.schulte@52north.org), Henning Bredel (h.bredel@52north.org)

Access Control for SOS Servers

Explanation: The OGC Sensor Observation Service specification allows the interoperable provision of sensor data through a standardised interface. However, this interface does not include a mechanism for access control (i.e. a way to determine which user is allowed to download which data sets). To close this gap, the 52°North Web Security Service exists (http://52north.org/communities/security/). This service was not specifically developed for SWE services. Instead the focus of this service is on typical mainstream OGC services such as WMS, Catalog or WFS. While prototypical support for the SOS 1.0 standard exists the current 2.0 specification is not yet supported. Within this project, this gap shall be closed by adding support for the SOS 2.0 standard. In addition, also the 52°North Sensor Web Client (http://52north.org/communities/sensorweb/clients/Thin_SWE_Client/Version_3.0/index.html) should be enhanced to allow the usage of SOS servers protected through access control mechanisms.

Expected results: Software module (servlet) providing a so called interceptor for the SOS standard (version 2.0).

Community and Code License: Sensor Web, Apache 2.0/GPL 2.0

Mentors: Simon Jirka (jirka@52north.org), Carsten Hollmann (c.hollmann@52north.org)

52°North Processing Server Dataset Resolver

Explanation: A general idea of web processing is to do the processing "close to the data", so instead of downloading or uploading gigabytes of datasets, we just tell a server that we want to run analysis A ond dataset D, and the server then resolves where to get that dataset in a most efficient way. This project should implement such a resolver for the 52°North Processing Server following the "eat your own dogfood" principle, i.e. by implementing the dataset-resolving-operations as web processes. This includes a lightweight Javascript client to add and manage the processes and a concept for extending the WPS capabilities and process description documents so that the available datasets are described. Examples of such mappings are

A potential student must be familiar with Java and web client development, preferably with a framework such as Spring, and be able to work in a larger development team. Experience with agile software development and the ability to produce intuitive and attractive user interfaces would be a great plus.

Expected results: A set of WPS processes to manage dataset access (add/remove/update dataset reference, list references, ... or similar) and a simple web client interface to interactively explore and manage available dataset mappings.

Community and Code License: Geoprocessing, GPL 2.0

Mentors: Matthes Rieke (m.rieke@52north.org), Daniel Nüst (d.nuest@52north.org)

Support of Pre-Defined Events in the Sensor Web Notification Client

Explanation: The SensorEventService allows users to subscribe to complex event structures described in a sophisticated markup language. For the SensorWebClient 52°North developed, a student must implement an easy to use client interface for this service to subscribe to pre-given sensors events (such as "temperature above X degrees celcius for the last y measurements"). This project should make the definition of such rules even simpler with the possibility to allow Sensor Web Client maintainers (domain experts) to define event rules that regular users can simply adopt. The Sensor Event Service allows subscriptions based on sensor stream patterns which can be rather complex. An intuitive method (e.g. based on popular Javascript libraries like JQuery UI or Dojo) to combine sensor streams (from different data sources instances) into patterns of observations should be developed and integrated into the overall Client user interface.

The student must be experienced in Java client development, preferably with experience in using the Google Web Toollkit (GWT) and Javascript. This project is of medium difficulty.

Expected results: An intuitive user interface to define sensor event patterns on different data sources for making advanced statements from transparently combined sensor events.

Community and Code License: Sensor Web Community, GPL v2.0

Mentors: Henning Bredel (h.bredel@52north.org), Matthes Rieke (m.rieke@52north.org)

Interactive Data Source Configuration for Sensor Web Client

Explanation: The sensor web client is one of the most advanced generic clients for the OGC Sensor Observation Service. With this project, we want to make adding new SOS service instances to the client a lot easier. Today, every service requires some programming to be integrated due to the complex structure of the "table of contents" of the service, the Capabilities document. This information has to be transformed to simpler "sensor stations" that users can select and visualise in the client. This project will develop an interactive data source configurator (potentially a wizard) to add new SOS to clients, considering aspects such as user levels (security) and performance (adding thousands of sensors).

The student should bring experience in Java software development with the Google Web Toolkit (GWT) and with XML documents. This project is quite challenging.

Community and Code License: Sensor Web, GPL 2.0

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

Open Sensor Search

Explanation: We want to take sensor data in the web to the next level by implementing the one stop shop for finding sensor data. This project fights this battle at two fronts:

First, the existing 52°North Sensor Instance Registry (SIR) implementation must be made more open: Registered users should be able to request a harvesting of their data source as well as provide their own harvesting implementation to integrate their metadata into the catalog of sensors. The potential student would also implement such harvesting mechanisms for popular sites such as Cosm and Thingspeak.

Second, the database interface must be switched out to something that scales and is really (!) quick, such as Apache Lucene and/or commercial cloud storage. The infrastructure should be tested with a simple search form with a good auto-suggest search field - you could call it "Google for Sensor Data" :-).

The student should have some experience in Java and an interest to scrape data from the net and put it in a high performance data structure. Experiences with Apache Lucene, XML and Database indices as well as cloud infrastructures are great but not mandatory. The complexity of this project itself is quite scalable.

Expected results: Scalable database backend for 52°North SIR, user management for open sensor search, public harvesting API with harvesting configuration UI for open sensor search.

Community and Code License: Sensor Web, Apache 2.0

Mentors: Simon Jirka (jirka@52north.org), Daniel Nüst (d.nuest@52north.org)

User Interface for Sensor Database Mappings

Explanation: The current database model of the 52°North SOS is complex, but of course for good reasons. If an SOS must be fit to existing databases, this can now be done with Hibernate configuration files. However, this is still a cumbersome task for many users. This project will extend the SOS Installer with a wizard to configure existing databases. The wizard should provide a self-explanatory GUI to create database mappings for hibernate, and support other databases in the SOS installer and admin interface (a last year GSoC project!).

This project is very challenging and requires the student to be profficient in Java software development (Spring, Hibernate) and multiple database servers (PostGreSQL, Oracle, ...).

Community and Code License: Sensor Web, Apache 2.0

Mentor: Carsten Hollmann (c.hollmann@52north.org)

SOS Performance Evaluation

Explanation: We "know" our 52°North SOS implemantation is quite fast and stable. But now we want you to put a number on it!

The student should have experience in Java development and XML and an interest in working down to the bits and pieces of software to find bugs and potential performance improvements. Of course we want to ensure functionality by using unit tests that the student also has to implement for some cases. Starting with an evaluation of existing performace testing frameworks (e.g. JMeter) the student will design and develop the tests in close communication with the core development team. If possible, these tests should be run based on a web application that also others can test their SOS with.

This project is less challenging on the implementation part, but the evaluation must be very well planned, designed and documented to be repeatable and a solid base for further testing. The tests results must also be fit for presentation to decision makers - beautiful graphs count. A potential student will get to know a highly modularized software and the transactional service interface of an OGC standard really well!

Expected results: A re-usable testing framework for SOS implementations (preferred as a Java web service), extensive and visual documentation of current state of play in SOS performance.

Community and Code License: Sensor Web, GPL 2.0

Mentor: Carsten Hollmann (c.hollmann@52north.org)

Sensor Web Discovery 2.0

Explanation: Currently it is hard for users to find a suitable sensor data set, be it metorological or hydrological, for live use.

How do you find the nearest weather station that provides measurements not older than 10 minutes independet from the platform that provides the data (OGC SOS, Cosm, Thingspeak, ...)?

This project will work on extending the data that can be captured and provided by the Sensor Instance Registry (SIR), with an open source implementation available in the 52°North Sensor Web community, and is related to the "Open Sensor Search" project idea. Here, we want to integrate discussion and user feedback mechanism into the user community to improve the metadata, which is often not given. Registered users can give feedback about the usability of a data source or give a "+1" or "like" a sensor and thereby support others in making informed decisions about which data they should use for their own analysis. Apart from popular social sites the integration of latest research on user feedback (GeoViQua project) for GEOSS should also be integrated. The order of search results naturally should reflect the user input (e.g. allow to sort after rating) and potentially other information (see for example http://www.vs.inf.ethz.ch/publ/papers/sensorranking.pdf).

Expected results: An interactive HTML5 client for the Sensor Instance Registry including map visualisation of sensor locations, an integrated display of data availability, a preview of the latest measurements of sensors, user-based ratings, and the possibility to submit comments and rankings about search results. A potential student should know Javascript and be interested in developing smooth and attractive user interfaces and visualisations on the web (ProcessingJS, d3.js, Leaflet, Modest Maps, ...). Some knowledge of social networks and their APIs is also helpful.

Community and Code License: Sensor Web, GPL 2.0

Mentor: Daniel Nüst (d.nuest@52north.org)

Quality Enabled Metadata Editing

Explanation: The ultimate use of all metadata and metadata catalogs is to assist users in answering a simple question: What data is there and is it fit for use in my specific problem?

A European research project, GeoViQua is dedicated to enabling services to provide help in answering that question and keeps a special eye on quality metadata: How accurate is the data, where are scientific documents describing the data, and so forth. To generate such information, it must be made very simple for data providers as well as users of data to contribute the information without going into the depths of XML documents and catalog service interfaces but with the help of a stable and intuitive user interface. The Metadata Community's smartEditor is such a software. In this project it will be extended with features and specifications developed in the GeoViQua project.

A promising student for this project has experience in agile software development based on Java, XML and XSLT. You will gain worthy experience in ISO standards and important aspects of professional geodata metadata management such as INSPIRE or the OGC CSW.

Expected results: Extension of the smartEditor with capabilities to enter and display quality metadata based on the GeoViQua producer and consumer quality models. For the consumer quality model, an interface to the feedback server must be implemented.

Community and Code License: Metadata Management, Apache 2.0

Mentor: Daniel Nüst (d.nuest@52north.org)

Web of Things Connector for SOS

Explanation: Cosm or Thingspeak are great platforms to build up your own sensor web with simple hardware and an easy to use protocol. But the OGC Sensor Web Enablement services have their advantages, too - interoperability for instance. We want to combine both advantages by implementing several small software components within this project.

  • A Cosm and/or Thingspeak backend for the SOS, so that SOS request are forwarded to the respetive backend and the response is translated to SWE data formats.
  • A Cosm and/or Thingspeak data harvester, in the former case based on their event interface, so that I can configure my SOS to "listen" to the other platforms or to harvest them on a fixed schedule. In both cases I can store selected data streams in my SOS (non-functional prototype exists for Cosm, see Geostatistics.Cosm2sos).
  • A Thingspeak database connector so that data inserted via the Thingspeak interface is actually stored in a SOS database. This could be done with direct database access conforming to the SOS database model or using the transactional service interface.
Both components will be developed as extensions the to the 52°North SOS. A potential student should therefore have experience in Java development and working with web services and their interfaces. However, this project is quite scalable with respect to functionality, so experiences with XML, JSON, and HTTP are great but not mandatory.

Expected results: An OGC SOS 2.0 compliant webservice that a client can access to download Cosm and/or Thingspeak data. A SOS that stores/mirrors selected Cosm data streams.

Community and Code License: Sensor Web, Apache 2.0

Mentors: Daniel Nüst (d.nuest@52north.org), Dustin Demuth (d.demuth@52north.org)

ESRI Geoservices REST API binding for SOS 4.0.0

Explanation:

ESRI is a global player in the GIS world and has recently brought the GeoServices REST API specification into the standardization process at OGC. This API provides a way to communicate with geoservices (e.g. mapping or feature services) through a simple REST API. The GeoServices REST API is e.g. supported by ArcGIS Server as an open API to allow flexible application development.

The 52°North SOS 4.0.0 implements the OGC SOS 2.0 standard. This SOS 4.0 implementation currently focuses on offering the standardized KVP and SOAP bindings of the SOS standard. However, we are also keen to extend the SOS 4.0 implementation to serve multiple other bindings in order to facilitate application development. For example, we have recently added our own RESTful binding to the SOS (see project description here).

Unfortunately, the currently implemented bindings are not supported by ESRI clients, such as ArcMap. I.e. it is not possible to connect an ESRI client directly to our SOS without installing an extension such as the ArcGIS SOS Extension.

Thus, this project aims at implementing an extension for SOS 4.0 to support the openly defined GeoServices REST API as an additional binding. This includes working on a mapping from the SOS 2.0 model to already existing ESRI services and the implementation of a ESRI Geoservice REST API for the 52°North SOS 4.0.0.

Good experiences in Java development are essential. Experiences with Maven are good. Experiences with ESRI technology would be helpful. Experiences with REST and JSON would be great, but not essential.

Community and Code License: Sensor Web, GPL 2.0

Mentors: Carsten Hollmann (c.hollmann@52north.org) and Arne Bröring (broering@52north.org)

Seismic Data Modeling in SOS

Explanation: This project idea popped up on the mailing list recently, and might need to be precised any time soon. I see a client-side (sensor web client) and server-side component (52N SOS 4.0.0) so far. The aim is to load, serve and visualise seismic data, which could be found in different places (USGS, GeoNet ... refrerences/links?) and in different formats. Seismic sensors deliver primary data. Earthquakes are located based on the input of the seismic sensors. Please investigate on accessible seismic data sources, e.g. from USGS, GeoNet or the German GFZ institute in Postdam. Please also have a look on some NZ GeoNet resources (here and here). I had a look at the QuakeML definitions, and it seems it can be used for eartquakes in terms of events as well as generic seismic data (but it is not a GML application schema, only GPS coordinates in lon-lat).

However, we want to translate that into OGC SOS interoperability space.

For the server-side of things, an alternative DAO could be implemented that sources seismic data from e.g. USGS and serves them as standard SOS/O&M. This includes further challenges, intelligent caching for example. Secondary an alternative output encoding, like QuakeML (also look here and here), could be implemented for the SOS server. Is there possibly a "SOS profile" appropriate?

For the client-side, intelligence about seismic data (conceptual) and the encoding is necessary and might be implemented in the sensor web client, to visualise seismic data. So it would be good, if you brought a good portion of Java and XML knowledge.

Expected results: We will have to make the seismic data available through the SOS server, the output may be O&M or even QuakeML and then a client wants to visualise things (earthquakes as point features and/or seismographs as a time-series plots). I think altogether might a bit too much (although depends on your programming skills and motivation) smile

Community and Code License: Sensor Web, GPL or Apache

Mentor: Alex Kmoch (alexander.kmoch@live.unigis.net), Carsten Hollmann (c.hollmann@52north.org) and Simon Jirka (jirka@52north.org) -- AlexanderKmoch - 2013-04-18

SOS Server Admin and (Exchangeable) Encoding Enhancements

Explanation: The 52N SOS server 4.0.0 architecture is very flexible and allows dynamic loading of "implementations against the SOS API" (have a look at the Java ServiceLoader API). We would like to allow users and developers to write, share and use encoders for different output formats for particular domains. The SOS Admin needs to be extended to support the management of such plugins (basically jar-files). This is challenging on a conceptual level, to understand internals of the 52N SOS implementation, OGC SOS spec and namespaces.

Expected results: Enable SOS server admin to upload and manage "encoding plugins", candidates to be documented and implemented, NetCDF and also from SensorWeb.SosEncodings

Community and Code License: Sensor Web, GPL 2.0

Mentor: Alex Kmoch (alexander.kmoch@live.unigis.net) and Carsten Hollmann (c.hollmann@52north.org) -- AlexanderKmoch - 2013-04-17

3D Community - Rendering 3D Scenes from OGC Web Services

Explanation: The 3D community develops the Triturus library and accompanying web services. This project would explore the rendering from OGC webservices to 3D scenes (eg. X3D or VRML). Basic example, calling WCS for a terrain (DTM/DEM), draping a WMS over the terrain (could be a topo map) and possible WFS or SOS sensor stations as point features. The 3D community is still in an early stage, which means we need a commited and self-engaging student, how likes to explore and communicate (not that this less important for the other projects, though smile )

Expected results: add functionality to or create a library that can be used together with the Triturs library within the 3D server.

Community and Code License: 3D Community, GPL or Apache

Mentor: Alex Kmoch (alexander.kmoch@live.unigis.net) -- AlexanderKmoch - 2013-04-17

Further Potential Mentors and Work Areas

Prelimenary/Coarse Project Ideas - Contact the Communities for Details!

Testing, Management, and Control

  • Development test suites for important products (unit tests, test driven development), such as ILWIS, SOS, WPS, clients, ... > How could this be related to CITE testing for services?
  • Performance measurements for service instances (based on Matthes' framework?)
  • Service statistics for SOS (which offerings are most frequently requested for which time periods, ...), WPS (run processes, most popular input formats, ...) and client statistics (what are are typical click-workflows within clients, e.g. ILWIS, Sensor Web Client)
  • Service supervisor (Extending the idea of OwsSupervisor with backend and user management for a front-end different users) -- DanielNuest - 2013-03-28
  • Advancing the SOS admin to actually enable encoding plugins management (and add plugins smile ) -- AlexanderKmoch - 2013-01-20
    • (requires) Generic and modular administration backend framework (project modules provide content for the admin backend = modularization/decoupling of the backend) -- DanielNuest - 2013-01-21
  • advancing SOS admin to integrate easy upload feeder (like the command line tool now) -- AlexanderKmoch - 2013-01-20
Connecting Communities
  • SOS client for ILWIS -- DanielNuest - 2013-01-21
  • SOS2.0/O&M2.0/WaterML2.0 for sos4R -- AlexanderKmoch - 2013-01-20 +1 -- DanielNuest - 2013-01-21
  • 3D Community - rendering from OGC webservices to 3D scene - like WCS terrain and WMS draping, SOS sensor stations? -- AlexanderKmoch - 2013-01-20
Integration and Re-using "Ying and Yang" - Clients and Servers
  • Develop clients (hard-typed interfaces) in as many languages as possible to make our service implementations accessible to as many people as possible
  • Connection has to make sense, focus on languages we are NOT strong in but which are popular (in areas we are not focussing on)
  • Languages: Java on Android, C# (iPhone!), Python, (R), C++, Ruby, PHP, Javascript
  • SIR client in HTML5 -- DanielNuest - 2013-03-27
  • NetCDF for WPS (and/or maybe as SOS encoding) -- AlexanderKmoch - 2013-01-20
"Reaching Out" - External Clients and Projects
  • Add sensor web as a data source into Marble (from the KDE Education project), http://marble.kde.org/, to include life environmental data. Potentially co-mentored, it is an active community. -- DanielNuest - 2013-01-22
  • integrate Feature handling with OXF -- HenningBredel - 2013-02-21
Project focus area: "Mobile future" - HTML5 clients

Project Template (add your idea above and leave this template intact)

Project: <concise 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>

Community and Code License: <if applicable>

Mentor: <full name and contact details>

Terms and Resources

Metadata

  • Topic created by: DanielNuest
  • Topic created on: 2013-02-15
Tags:
create new tag
, view all tags
Topic revision: r29 - 2013-04-21 - 09:18:44 - CarstenHollmann

 
  • Search: 
This site is powered by the TWiki collaboration platform Copyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback