52°North Spatial Information Research GmbH

exploring horizons

Blog

Welcome Google Summer of Code 2013 students!

by 2 Comments

Filed Under: Geoprocessing, Geostatistics, GSoC, Sensor Web Tagged With: , , , , ,

52°North is pleased to welcome the following students to work with us closely this summer on four Google Summer of Code projects!

  1. Mohammad Ahmed Hamed Yakoub (from Cairo, Egypt) will tackle the ” Open Sensor Search” project (Sensor Web Community) and implement a one stop shop for finding sensor data.
  2. Khalid Alqinyah (from Riyadh, Saudi Arabia) will spend the summer working on the “52°North Processing Server Admin Interface” (Geoprocessing Community) and transfer the current HTML/JSP approach to a modern and flexible web application framework.
  3. Patrick Noble (from San Luis Obispo, CA, USA) will make seismic data from a variety of different sources available through the SOS  in the “Seismic Data Modeling in SOS” (Sensor Web Community) project.
  4. Jinlong Yang (From State College, PA, USA) will implement and/or improve generic classes, methods and tools for handling and analyzing large-scale trajectory data with R in the “Trajectory Analysis in R” (Geostatistics Community).

more >

SOS Administrator: A new user experience starts now!

by Leave a Comment

Filed Under: 52°North, GSoC, Sensor Web Tagged With: , , , , , , , ,

The end of Google Summer of Code is a new beginning of the SOS Administrator. This year, the SOS Administrator project aimed to improve the user experience with 52°North Sensor Observation Service (SOS) and make its administration more intuitive. We tried to achieve that goal by making 52°North SOS installations just a matter of few clicks. First stepping stones were also laid out to facilitate SOS administrators by getting together useful features within a adminstrative backend.

The web-based SOS Installer is a really handy tool for inexperienced users who want to try the 52°North SOS, but also an equally useful tool for experienced users who appreciate a simpler and quicker installation procedure. You deploy the standard SOS web archive and visit the installer page. The wizardmore >

Demonstrating Exchangeable Encodings for SOS: A Quantum Leap for me

by Leave a Comment

Filed Under: 52°North, GSoC, Sensor Web Tagged With: , , , , , , , , , ,

The final sprint towards the end of the Google Summer of Code (GSoC) is over now. After fixing bugs, working on documentation and actually producing time-series in different formats, the “Exchangeable Encodings for SOS” project met most of its ambitious goals – and it is demonstrated on the 52°North Google summer of Code Demo Server. Users and developers documenation on the encoding mechanism has also found a place in the 52°North wiki.

We have integrated a plugin mechanism into an SOS server (source code branch), which is based on the main 52°North SOS development line (source code trunk). As a proof of the concept, two basic plugins are provided:

  • Plain CSV (comma separated values) response format, which tries to stick to recommended NOAA IOOS Data Integration Framework CSV output,
  • WaterML 2.0 (OGC WaterML 2.0 and Hydro DWG). I acquired a recent version of the WaterML 2.0 encoding profile, which is already adopted as a (candidate) standard. The schemas are not yet officially published and rumours have it that there might be last minute changes. The change request contains an extension regarding empty time-series responses which should not interfere with the existing implementation.

In the world of many diverse forms of observation types for natural phenomena, the two plugins demonstrated both rely on point-based measurement data.

Where to go from here?more >

xmlcodegen: Why you should generate Geotools bindings for your XML map data

by 3 Comments

Filed Under: Geoprocessing, GSoC Tagged With: , , , , , , , , , , , ,

So as you may or may not have been following my blog posts or status reports recently, I’m currently a Google Summer of Code 2012 student for 52°North. My project primarily deals with the problem of providing bindings for OpenStreetMap data such that they may be used within the Web Processing Service (WPS). Yet here I am talking about xmlcodegen, a component that is primarily part of Geotools… why?

It turns out that the WPS relies a lot on Geotools to for handling various map data types. This makes sense, as Geotools itself is intended to provide an easy way to interact with various geospatial data formats. By making use of Geotools, WPS can tap into its features and capabilities, and thus support interactions and manipulate all these data formats without necessarily having to reinvent the wheel for each file format. The same goes for any other projects or packages that make use of Geotools.

As such, when the task came to implement bindings in WPS for OpenStreetMap data, I naturally looked into the capabilities of Geotools to see if such functionality was already provided. It turned out that it was not, however mechanisms existed to easily implement such functionality; this was exacerbated by the fact that OpenStreetMap data was primarily in XML format.

This blog post is mostly dedicated to my experiences in generating bindings for Geotools from XML-based file formats. It is meant to supplement Geotools’ articles in terms of some of the problems I encountered, and the solutions I found for them. I also will give a brief overview as to the progress of the project thus far.

Disclaimer: I don’t in any way claim to know all there is to Geotools’ xmlcodegen process, nor in any way act as the authoritative answer for solutions to the issues I address.

What is XML? Why is knowing this important in the context of OpenStreetMap?

XML is a markup language. In the context of OpenStreetMap data, it is primarily used as means to transport and convey map data in a meaningful format to both humans and machines. As such, it tends to be considerably more verbose than other file formats (consider a 303GB uncompressed OSM XML planet file, compared to its 21GB OSM PBF relative), however this verbosity is mitigated by the fact that several mature libraries and tools already exist to handle this file format. Consider for example, all of the ways in Java to interact with XML:

more >