Sensor Web, Geoprocessing, Security & GeoRM, Geostatistics, Semantics, 3D, Ilwis, Earth Observation

Linking GIS and WoT – The Video

July 11th, 2012 @ 10:58 by Sidhant Hasija
Posted in GSoC

This blog post presents the progress of the Google Summer of Code Project GIS Link to the Web of Things. The purpose of this project is to enable a user to communicate with “things” in the WoT paradigm using available GIS and geobrowser software running on a computer or mobile platform. The methodology of communication uses regular HTTP GET requests to which the server hosted by the thing responds with a KML file. KML is an open XML standard for geographic visualisation and is well suited to carry geographic information. The file received is then displayed by a KML viewer, such as Google Earth or ArcGIS Explorer.

The video demonstrates how I programmed an Arduino Mega 2560 with web connectivity provided by an Arduino Ethernet Shield to respond to specifically structured requests from Google Earth. The response is a KML file and depends upon the type of GET request. The vision is to program such a server on thousands of digital devices and control them from a remote location using GIS software. The applications of such a scenario can be vast and promising.

GIS Link to the Web of Things Demo Video

To be more specific, the readings of multiple sensors attached to the Arduino platform are internally stored in a csv log file. Sensor readings alone are insufficient to provide a complete picture of the sensor state. Therefore date, time and geo-coordinates obtained from an on-board GPS unit are also stored with each sensor measurement. Upon request from the client, multiple Placemarks (one for each measurement) are embedded into KML file along with the timestamp information so that a user can easily filter out the information he/she wants while interacting with the timeline user interface.

The work above proves the concept, but still defines just a first step and a lot of innovation and improvement lies ahead. Moving on further, another possible way to maintain the link is through the GeoServices REST API and JSON exchange. In that way, a smooth exchange of data between ArcGIS GIS software and web enabled things can take place.

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

July 6th, 2012 @ 15:00 by Sarah Harvey
Posted in Geoprocessing, GSoC

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:


SOS Installer is here! Back-end to follow

July 6th, 2012 @ 08:30 by Shubham Sachdeva
Posted in GSoC, Sensor Web

Halfway through GSoC and the SOS administrator project is half done… well almost! The web-based installer for SOS is up and running and only needs a few tweaks before an alpha release, which should be available online in the coming week.

What does the installer do? It asks for minimum information from the user and almost automatically sets up the SOS for you. You don’t even need to create a database manually anymore! You want to add dummy data initially? Go ahead and just enable a checkbox during installation and it’ll be done. You installed a PostgreSQL database and still couldn’t setup a connection. Don’t worry, the installer will help you in connecting with the database. And if anything goes wrong, it will help you in determining exactly what’s wrong.

Here are a few screenshots of database related screens:
Database configuration

Exchangeable Encodings Getting in Shape

July 4th, 2012 @ 08:00 by AlexanderKmoch
Posted in GSoC, Sensor Web

The time is flying by and soon we reach midway of the Google Summer of Code (GSoC) with 52°North. It is the typical time in between – I already managed to meet the first milestones, but there is no proper product yet. Catching up with the changes from the SOS main development branch is a constant challenge, but the infrastructural changes within the “Exchangeable Encodings for SOS” project are slowly but continuously leading towards a robust and standardized, yet limited, encoding plugin API (application programming interface).

The main use case is the request for observations (GetObservation request) that could be delivered in CSV (comma separated values) format for legacy applications, WaterML2.0, an upcoming OGC (Open Geospatial Consortium) data transfer standard for the hydrological domain, possibly netCDF (Network Common Data Form), also an OGC standard for meteorological applications, and in O&M (Observations & Measurements) for the generic use within sensor networks and spatial data infrastructures.

An open question is whether there is a need to also encode sensor and feature information in different format (affecting DescribeSensor and GetFeatureOfInterest requests). And which other encoding schemes would be interesting? Please add your ideas in the comments! We are starting to document the preliminary API on the project’s wiki site: