Motivation

The number of services available for geo data and geo applications is constantly increasing. This creates potential for new types of applications, which rely in particular on the combination of these services. A central problem is to combine and integrate the services in a suitable way, both on a conceptual level and in terms of programming. In client-server environments, this applies both to the server-side application and to the client.

On the server side, flexibility is achieved through the various geo services of the OGC (Open Geospatial Consortium), such as Web Map Service (WMS), Web Feature Service (WFS), Web Processing Service (WPS) or Sensor Web Enablement (SWE). the combination of these services still involves a relatively large amount of effort. This is especially the case when geo services are to be linked to resources other than those of the OGC standards.

There are basically two implementation approaches in the client/portal area. First of all, the pure frameworks, which allow full freedom, but mean a lot of programming effort. In addition, the finished clients/portals, which are designed more for dedicated web GIS applications. The aim is therefore the conception and development of a generic system that can manage and, in particular, link different geo services. The result should be usable or expandable for different tasks and offer sufficient interfaces for further developments in terms of input, administration, analysis and presentation.

Activities

In a first phase, a well-founded general concept was developed and suitable available components were selected. The Liferay portal software was chosen for the user interface. This already offers some basic functionality and can be easily expanded with your own components (portlets, services, hooks). The use of portlets also allows later applications to be flexibly assembled. The basic system has already been created and the first prototypical extensions have been developed.

Since the flexible combination of services and resources should also be possible on the server side, it must be ensured that they are very strongly decoupled via modules in the program. The tasks can then be defined in workflows composed of a series of steps. In the simplest case, these workflows consist of an input, which is then processed, and an output, to which the data is given. Modules are currently being developed that provide interfaces for data sources, processes and data storage based on Spring Framework projects (SpringXD, Spring Integration, Spring Social, Spring Data).

In an example scenario, the possibilities of the prototype are examined. For this purpose, a social media analysis tool is being developed, which takes up the basic idea of ​​Tweetmap (http://tweetmap.fh-mainz.de). Tweets on specific topics are to be processed in a sentiment analysis and then made available in the sense of Human As Sensors in a geo-sensor network via a Sensor Observation Service (SOS), which is part of the SWE.

Results

The current prototype is based on the architecture model from Figure 1. As additional portal components, there is a first map application and its level management. In addition, there are first tests of a chronological diagram visualization, which is to be used later for chronological navigation/filtering. Various services were set up on the server side and the first modules for a workflow were developed. This currently mainly includes input and output modules, such as a Twitter interface and the provision of this data as a sensor in an SOS. This means that a background process, which, for example, collects the Twitter message on a topic and writes it to the SOS, can be defined as in a UNIX shell [Figure 2]. The “pipes” define the channel used by the individual modules. All modules and the channel can be on different servers. The workflows are also managed via a web interface. In the next step, the developed modules are to be expanded and further modules, especially for data processing (e.g. Twitter sentiment), are to be developed. In addition, the interfaces to the user application (portal) must be established.