GIS data typically represents state at a specific moment in time: “historic”, “current”, or “future”.
However, there are some important trends that deviate from this static pattern.
An increasing number of data from social networks
The availability of existing and new sensors of any kind.
Real-time GIS data is a continuous stream of events flowing from sensors, where each event represents the latest state of the sensor.
There are many examples of such sensors including cars, tweets, traffic, smart home metering etc.
How do we deal with real-time GIS data? What steps are included. Let‘s have a look at the 3 steps that make up the general workflow.
First, we obviously need to connect to our sensors. By nature, each sensor speaks his own language. Or more technically, uses his own protocols to encode and transport the real-time data.
Second, we need to diggest the received information. Likely, we do want to filter down the data to a subset that is of interest to us. This could be …
And finally, we want to act upon certain events.
Das neueste Release von ArcGIS for Server (10.2) ermöglicht die Einbindung von Big Data und Echtzeit-Daten. Es wird damit zwei wichtigen aktuellen Trends Rechnung getragen: 1) die ansteigende Verfügbarkeit von Daten aus sozialen Netzwerken, 2) die Verfügbarkeit bestehender und neuer Sensoren in einer wachsenden Vielzahl von „Trägern“.
Esri has a solution for this, the GeoEvent Processor.
http://www.esri.com/software/arcgis/arcgisserver/extensions/geoevent-extension
http://pro.arcgis.com/share/geoevent-processor/
Esri has a solution for this, the GeoEvent Processor:
Integrates real-time streaming data into ArcGIS
Performs continuous processing and real-time analytics
Sends updates and alerts to those who need it where they need it
http://www.esri.com/software/arcgis/arcgisserver/extensions/geoevent-extension
http://pro.arcgis.com/share/geoevent-processor/
Let‘s walk through the general workflow again and see how GeoEvent Processor adresses the 3 steps involved.
Input connectors, as said already, take over to connect ArcGIS to our data sources.
Esri is focusing on common data sources that …
However, you might encounter more industry specific data sources. In that case a look at the gallery might be worth the effort.
Once we have made the real-time data available to us, we probably want to do something with it.
This actually falls apart into 2 parts.
First, we want to filter down to those data that actually are of interest to us.
Then, we acutally want to further process the data, e.g. enrich that data.
Hier eine Übersicht der verfügbaren Filter und Prozessoren.
Field Enricher: Erweitert Geoevents um Attribute aus einem FeatureService oder einer Textdatei auf Basis einer tabellarischen Verbindung (Join).
Field Reducer: Reduziert GeoEvents um eine festgelegtes Set von Feldern.
Field Calculator: Berechnet neue Datenfelder aus existierenden Feldern über mathematische Ausdrücke oder Textmanipulation.
GeoTagger: Berechnet für jeden Geoevent räumliche Beziehungen aus einer Liste von digitalen Zäunen (Geofences) – IN, OUT, ENTER, EXIT
Field Mapper: Setzt Input Geoevent Definitions in Bezug zu Output Geoevent Definitionen über ein festgelegtes Feld
Track Gap Detector: Ermittelt das Nicht-Eintreten von zu erwartenden Ereignissen und informiert entsprechend.
Incident Detector: Ermittelt, aktualisiert und verwaltet Ereignisse für jeden Geoevent auf Basis festgelegter Bedingungen
Während die Verwendung von attributiven Filtern keiner weiteren Erläuterung bedarf, hier zur Verdeutlichung die Möglichkeiten der kontinuierlichen räumlichen Filterung:
Inside/Ouside-Events: werden jeweils ausgelöst, solange ein Objekt sich innerhalb bzw. außerhalb einer Geofence befinden
Enter/Exit-Events: werden jeweils in dem Moment des Ein- oder Austretens eines Objektes in einen bzw. aus einem Geofence heraus ausgelöst
Architektur basiert auf OSGi mit Apache Felix als Framework