Group Output GeoEvents by Category
Does anyone have a workaround for this? See visual below.
Generally speaking, each GeoEvent processed through a GeoEvent Service is independent. We don’t know when an event is going to arrive, and out-of-the-box processors do not cache event data – with a few exceptions. A Track Gap processor, for example, will cache the field tagged TRACK_ID and the date/time the last event with the cached TRACK_ID was observed … obviously so that it can produce an event when its timer expires and it determines that an event with TRACK_ID has not been seen in the specified time. A filter will cache some event information if it is configured with an ENTER or EXIT condition, since it has to know something about the previous event in order to determine if the event just received has entered / exited an area of interest.
Our backlog of enhancements for 10.4 includes the concept of node-level caching, event aggregation, and temporal filtering. Big topics all, but enhancing the underlying implementation to provide node-level caching – so that any given processor / filter in a GeoEvent Service could interrogate a cache to retrieve a set of events previously received – would allow the development of an “aggregator” processor which could provide some basic statistical analysis:
- Send a single event out every 30 seconds whose Capacity field value is the largest observed
- Send a single event out every 30 seconds with an average of all of the observed Capacity values
- Sent a summary (or count) of all events received over the last 30 seconds which satisfy some attribute or spatial expression
We’re eliciting requirements in these areas. I cannot commit that they will make the 10.4 release. My suspicion is that the 10.4 focus will be on increasing event throughput from “thousands” of events per second to “tens-of-thousands” of events per second. Obviously this presents a challenge to any sort of node-level caching enhancement. Just how much data to we expect GeoEvent to cache and which system resource (disk or memory) is going to take the hit?
You might consider experimenting with the new spatial relationship operators available to filters – introduced at the 10.3.0 release. We tend to think of GeoFences as polygon areas then test to see if an event’s Geometry (a Point) is “inside” or “outside” the GeoFence.
But the geometry of a GeoFence is not limited to a polygon. You could import a set of point features as your GeoFences and if the Geometry of a received event is a polygon, a filter could check to see which point GeoFences intersect the polygon event Geometry. A GeoTagger then, which is just a particular combination of a spatial filter and an event enricher, could produce a comma-separated list of the name of each point GeoFence which intersects a received polygon event Geometry.
Here are the new spatial operators available for GeoEvent filtering (introduced with the 10.3 product release):
Hope this information helps –
RJ
