[Article] Geo Spatial Data Analysis Using WSO2 Complex Event Processor

  • By WSO2 Team
  • 21 Jan, 2015

Table of contents

  • Introduction
  • Features available in geo-dashboard
    • Show real time spatial data on the map (with object rotations)
    • Speed alert
    • Proximity alert
    • Stationary alert
    • Geo-fence alerts
    • Add external tile URLs and web map service (WMS) endpoints
      • Slippy map and tiles
      • Web map service
    • History playback
  • Summary

Introduction

We live in a fast-moving world today. People are rapidly moving forward with technology and their actual physical lives. Keeping track of those movements has become critical for regular people and as well as for enterprises. There are several ways to obtain location data about an object, such as through GPS satellites and cellular positioning techniques via GSM networks. However, just a collection of data does not have any real value unless we process these to generate meaningful information. It creates a new question regarding how we can process huge amounts of spatial data generated by a location device. This is where WSO2 complex event processing (CEP) comes into play.

For precise measurements, calculations or to display spatial data, we need to have them in real time. However, the problem is that real-time events come from a large number of devices and generate massive amounts of event streams. WSO2 CEP is capable of analyzing data that comes from different types of streams at a high rate and obtaining useful information out of this data. This article explains how we can process spatial data from an external source of events and analyze/manipulate this data to produce meaningful information to end users, while hiding the complex CEP process with the WSO2 Jaggery UI application.

Features available in the geo-dashboard

The WSO2 geo-dashboard is based on three previous projects that were done as proof of concepts. The geo-dashboard comprises the features in those three projects with the new CEP query structure allowing the addition of dynamic geo operations with some UI improvements to minimize exposing users from CEP configurations.

Show real time spatial data on the map (with object rotations)

With the CEP geo-dashboard, users can see the movements of spatial objects in real time, including their rotations in the space. WSO2 CEP accepts any type of input data through its supported input adaptors (Figure 1).

Figure 1

Events that come via an input adaptor go through an event builder to map the data attributes in the specific event format to Siddhi event attributes to process them by the Siddhi engine. For demonstration purposes, we have used an HTTP input adapter to collect events that are sent from the sample data producer in JSON encoded format, then we put them into rawInputStream for further processing. After processing the event by the Siddhi engine (discussed later in the article), we format the event into our desired output format, and output the event through an output adaptor.

In the CEP geo-dashboard, spatial object data is transferred as a GeoJson[] object from the CEP websocket output adapter to the web browser. This allows us to loosely couple the front-end application with CEP. A marker on the map is placed using the GeoJson point, which is received from the CEP and keeps an array of spatial objects to update the location as the events coming in. We have used properties member of the GeoJson structure to send custom attributes such as speed, heading, state, and information data. We have used the Leaflet[] javascript framework to handle map data on the browser.

Figure 2

Speed alert

Speed alerts are the most simplest form of alerts we currently have. Users can set a specific value (in ms-1) for the speed limit and it will be set as a global value for all spatial events passing through the CEP. Figure 3 shows an example of a CEP Siddhi query used to trigger speed alerts.

  
from dataIn[speed >= 34]#transform.geo:subscribeExecutionPlan()
select id , latitude, longitude,timeStamp, speed, heading ,eventId , "ALERTED" as state, "This vehicle is going over speed!!" as information
insert into dataOut;
from dataIn[speed 

We have used XML templates of the execution plans as a convenient way of keeping the structure of the execution plans rather than typing them in the source itself. This templating mechanism will be discussed in detail later in this article.

Proximity alert

Proximity alerts are triggered when two or more objects (vehicles) become close in their proximity by a predefined value from the user. When two or more objects become closer in proximity based on the user defined value, we change the state attribute of the event to ALERTED, which notifies an alert in the web app UI.

Figure 3

Users can define a proximity zone by drawing a circular area centering an object and assign a time constraint for how long the second object needs to keep in close proximity in order to trigger an alert. Similarly, speed alert also applies globally where if any two or more objects become closer than the user defined value, an alert will be triggered from the CEP.

  
from dataIn#transform.geo:subscribeExecutionPlan()
select id, latitude, longitude, timeStamp, speed, heading, eventId,geo:geoProximity(50,latitude,longitude,id,timeStamp,20) as proximity
insert into innerStream;

from innerStream[proximity == "false"]
select id , latitude, longitude,timeStamp, speed, heading ,eventId , "NORMAL" as state, "" as information
insert into dataOut;

from innerStream[proximity != "false"]
select id , latitude, longitude,timeStamp, speed, heading ,eventId , "WARNING" as state, proximity as information
insert into dataOut;

Stationary alert

Stationary alerts are used to notify the users about the state changes in a predefined geo stationary. If a device stays within a predefined buffer-zone stationed for a predefined period of time, an alert will be generated and it will be displayed as shown below.

Figure 4

Stationary alerts are triggered using geo-withinbuffer extension in the CEP. It checks for a particular event location with the defined stationary zones and checks whether the current event is located within the defined zone. If that is true, it then calculates the time spatial objects have remained in the defined stationary zone, and if both become true, we change the event state to ALERTED and append the appropriate information about the alert. The following WSO2 CEP execution plan has been used to trigger stationary alerts from the incoming spatial events.

  
from dataIn#transform.geo:subscribeExecutionPlan()
select id, latitude, longitude, timeStamp, speed, heading, eventId,geo:withinstationery(longitude,latitude,"{'type':'Point','coordinates':[79.87062692642212,6.883652362379861],'radius':360.8415505794831}",id,timeStamp,3) as isStationery
insert into innerStream;

from innerStream[isStationery != true]
select id , latitude, longitude,timeStamp, speed, heading ,eventId , "NORMAL" as state, "" as information
insert into dataOut;

from innerStream[isStationery == true]
select id , latitude, longitude,timeStamp, speed, heading ,eventId , "ALERTED" as state, "This vehicle is in Harbour_bus_stop area!!!" as information
insert into dataOut;

Geo-fence alerts

Geo fencing allows users to set up triggers such that when a device enters or exits the defined geometry boundaries defined by the user, it pops up an alert in the dashboard. Geo fencing has many practical uses. For example, a school administrator can set up alerts so when a school laboratory tablet device leaves the school premises, the administrator can disable the device. A marketer can geo-fence a retail store in a mall and send a coupon to a customer who has downloaded a particular mobile app when the customer (and his smartphone) crosses the boundary.

Figure 5

The algorithm used behind the geo-fencing operations is, we convert the user drawn area to the geoJson format and input it as a constant to CEP geo-fence custom extension. When an event is received to the CEP, its coordinates are checked against the user defined fence for whether it is within the defined boundaries or not, using the OSGeo GeoTools library. The following sample query shows the usage of geo-fencing custom extension (iswithin) in Siddhi queries.

  
from dataIn[geo:iswithin(longitude,latitude,"{'type':'Polygon','coordinates':[[[79.8564863204956,6.947045831920686],[79.85642194747923,6.946747629898817],[79.8564863204956,6.947045831920686]]]}")==true]#transform.geo:subscribeExecutionPlan()
select id , latitude, longitude,timeStamp, speed, heading ,eventId , "ALERTED" as state, "This vehicle is in Kotahena_area restricted area!!!" as information
insert into dataOut;
from dataIn[geo:iswithin(longitude,latitude,"{'type':'Polygon','coordinates':[[[79.8564863204956,6.947045831920686],[79.85674381256102,6.948643339531811],[79.85577821731567,6.945128815623514],[79.85601425170898,6.945533519714717],[79.85620737075806,6.94600212401683],[79.85629320144653,6.946342926852387],[79.85642194747923,6.946747629898817],[79.8564863204956,6.947045831920686]]]}")!=true]
select id , latitude, longitude,timeStamp, speed, heading ,eventId , "NORMAL" as state, "" as information
insert into dataOut;

Add external tile URLs and web map service (WMS) endpoints

Slippy map and tiles

The slippy map is an Ajax component. JavaScript runs in the browser, which dynamically requests maps from a server in the background (without reloading the whole HTML page) to give a smooth slippy zoomy map browsing experience. The implementation of this is provided by a javascript library Leaflet. The map image is built up of many little square images called "tiles". These are rendered and served from a "tile server".

A tile server typically does not render tiles in real time for each user browsing the map. The tiles are rendered ahead of time and stored on the disk. Even so, relatively few rendering programs have a proven track record for serving high traffic regularly updating worldwide maps.

Figure 6

There are different tile servers that are specialized for rendering geographical information on a particular area or place, such as OpenCycleMap and OpenSeaMap. In the geo-dashboard, we can add new tile-servers so that users can see the maps with different detail levels. The default tile server for the dashboard is openstreetmap. This feature allows the users to add dynamic map layers to the dashboard allowing them to show spatial objects on top of their desired map layer.

Web map service

A web map service (WMS) is a standard protocol for serving georeferenced map images over the internet that is generated by a map server using data from a GIS database. The response to the request is one or more map images (returned as JPEG, PNG, etc.) that can be displayed on a browser and desktop applications. Geo-dashboard has a feature to add new WMS endpoints so users can see their spatial objects on top of a given MWS service map layer. For example, if a corporate user already has a web map service that serves their GIS data through WMS service, they can add the WMS endpoint to the geo-dashboard and locate their spatial objects (i.e. Vehicles, People, Mobile devices, etc.) on top of their private WMS layer.

History playback

History for speed and movement of the spatial object is available within a browser session. For better user experience, we have limited the speed history values to last 20 records. You can search for spatial objects by their object IDs (i.e for vehicles: vehicle registration number, for mobile devices: mobile IMEI/SIM number). As shown in Figure 7, the object travel path will be drawn on the map and the alerted sections will be drawn in different colors according to the predefined colors for those alerts. The path will also continue to draw in real time after selecting the object. Users can also see the speed history graph of the selected object on the right-side panel.

Figure 7

For each individual objects we keep their alerts triggered locations in the database for further reference. Users can click on the alert history point to see the alert type and information. You can see how it works here.

Configure and setup geo-dashboard

The following is a list of steps on how to setup WSO2 CEP to run the geo-dashboard application.

  • Get the latest WSO2 CEP stable build from here
  • Create a MySQL database called wso2_geo or run the MySQL database setup script found at this path [CEP_HOME]/samples/artifacts/1100/jaggeryapps/geo_dashboard/conf/setup_dashboard/mysql-config/geo_db_setup.sh to configure MySQL database to store alert toggle notifications
  • Run the CEP server using sample configuration, e.g. ./wso2cep-samples.sh -sn 1100 See below for more information

Starting the WSO2 CEP server

For instructions on starting the server with a sample configuration, refer to Starting sample CEP configurations.

  • Default username and password for sample data source are root. If those attributes are different, edit the created data source called mysql_db in the CEP management console using the following steps.
    • Log in to CEP management console, to edit the data source. Use admin as the username and password
    • Click configure, and then click edit on created data source (mysql_db) under the Data Sources menu
    • Then you can change the username and password if needed
  • You can access the geo dashboard using the following URL: http://localhost:9763/geo_dashboard/ Then log in to system using admin as the username and password

Summary

Geo fencing allows users to set up triggers such that when a device enters or exits the defined geometry boundaries defined by the user, it pops up an alert in the dashboard. Geo fencing has many practical uses as explained in this article. Among key features in the geo-dashboard are geo-fencing, history playback, proximity alerts, and the ability to add external tile/WMS URLs and stationary alerts. A user can also leverage WSO2 CEP to extract meaningful information from a geospatial events stream.

About Author

  • WSO2 Team
  • WSO2