The sensor web is a broad concept about making sensor data available online. There is no such thing as “the” sensor web, but several systems for different purposes. This makes it really hard to discover sensors and their data. Therefore, I will implement the Open Sensor Search (OSS) idea for the Google Summer of Code 2013 (see wiki page). Based on the exisitng Sensor Instance Registry (SIR), we will work on a system using a fast and probably distributed search engine. …
Trajectory analysis has a wide range of applications in various fields such as geoscience and social science. Use cases span across mobile phone users (see image below) e.g. for commuting analysis, ship and flight paths or animal tracking. With the avalanche of GPS-annotated data in the past few years capturing such data became much easier, so today there is a need for tools that are specifically tailored for analyzing large-scale trajectory data (example).
R, as a software environment for statistical computing and graphics, has been favored by researchers from various disciplines for its free access, rich statistical methods, and easy-to-share features. However, the classes and methods specifically developed for trajectory analysis are limited and domain-orientated in R. This project intends to address this issue by implementing and improving generic classes and methods for trajectory analysis. (more…)
This is the first blog post for the Google Summer of Code 2013 project being organized by 52°North and me with the goal of adding support for seismic data in the existing applications Sensor Observation Service (SOS) and Sensor Web (SWE). These applications currently function in unison to provide a user with sensor data; to display both the sensor location on a map, as well as the corresponding graphical information the user asks for. The data formats that are supported right now are based on climate and hydrology sensing and the applications have so far existed for the purpose of analyzing this sort of observation information. This project’s outcome (more…)
This week, we will have one blog post by each of this year’s Google Summer of Code students presenting their project and themselves. First off is Khalid – enjoy!
The current web application for the 52° North Web Processing Service (WPS) admin is very inflexible and highly coupled. Functions and modules are implemented directly into the presentation elements, making it difficult to add new modules and maintain the code. In addition, the interface is limited and somewhat outdated and new functions are desired. This Google Summer of Code project aims to change that.
The 52°North WPS implementation shares one important property with the specification – it is very flexible and can be used for many different use cases. A number of parties contribute, which results in a number of active development branches for code. We present a selection in blog posts in the series “A look into WPS branches”.
Conflation With Provenance – Custom WPS Processes
Similar to the efforts on Aviation-specific processing, 52°North developed processes for conflating two distinct data sets in the scope of the OWS 9 test bed. This article sheds some light on the details of the processes and the obstacles which need to be overcome.
Conflation is understood as a sophisticated process of unifying two or more separate data sets that share certain characteristics into one integrated all-encompassing dataset. In the process, different representations of a feature get folded into one feature. That target feature follows a particular model that is used to capture complementary information. In addition to the actual dataset conflation, the consistent capturing of provenance information was another goal of the project. The conflation processes developed represent a very customized and complex workflow. The test bed proved that the 52°North WPS framework fits perfectly into such use cases by providing an individual and flexible processing API.