GeoEvent: Enter/Exit Events
One of the most powerful things you can do with GeoEvent is monitor spatial events to determine how your real-time assets are interacting with each other. But sometimes, using the spatial operators in the various processors provided by GeoEvent can be intuitively challenging. Below are some patterns (and anti-patterns) that might be useful.
- Cached vs. Non-Cached Spatial Operator
- Filters
- Filter-GeoTagger Anti-Pattern
- Anti-Pattern Details
- GeoTagger-Filter Pattern
- Cached Spatial Operations + NULL
- Additional Discussions
- Cached Operation Settings
- GeoEvent Documentation
- The following blog
Cached vs. Non-Cached Spatial Operator
Most of the spatial operators are non-cached, meaning that they don't require any knowledge of where an asset has been. Examples of non-cached operations include inside/outside, intersects, and disjoint. Evaluating these conditions can be done immediately and without any other information other than two geometries.
On the other hand, cached operators require more information than just one event can provide. An example of a cached operator is Enters. In order to determine if an event has entered a goefence, the operator needs to know where the event was before the current event. In order to perform the operation, the operator must cache the previous location of each TRACK_ID so that it can know where that asset has been.
Filters
Filters are special processors that allow events to pass or not based on a predetermined set of conditions. Those conditions can be based on either attribute values (speed > 20) or on spatial conditions (inside a geofence). Filters can also evaluate the cached spatial conditions such as Enter/Exit.
The general guideline is to filter events as soon as possible in your GeoEvent Services to reduce the overall processing load. Combine this with the fact that evaluating spatial conditions can impose a slightly larger processing load when compared to determining attribute conditions ("speed > 65" will probably be computationally easier than "point inside polygon") and it makes sense to try to remove events as early and easily as possible. An example of a good practice for using a filter to limit your spatial analysis might be:
Filter-GeoTagger Anti-Pattern
But one must keep in mind that using a cached spatial operator within a filter will only pass the event that has met the conditions. This may impact processors down-stream of the filter, if they are also implementing a cached spatial operation. This brings us to our first Anti-Pattern: Filters remove events that some cached spatial operators need.
Let's say you want to process truck locations that are entering or exiting a yard. Based on your knowledge, you know that there will be a lot of GPS locations that have nothing to do with entering or exiting the yard so you place a filter at the beginning of your service. But you also want to know what yard the truck entered/exited, so you use a GeoTagger to capture the name. The resulting service might look something like this:
You will find that this does not work for the following reason: The spatial operation in the GeoTagger is a cached operation, so it requires two (2) events to determine the enter/exit condition of a truck (one outside and one inside). However, the filter at the beginning is only allowing one of the two required events to pass. Combine this anti-pattern with the global settings "First Event Triggers Enter = TRUE" and "First Event Triggers Exit = FALSE", and you will find it causes unexpected behavior and should be avoided.
Anti-Pattern Details
The filter is masking event records the GeoTagger needs in order to correctly determine Enter / Exit. Each node maintains its own cache of observed events (one reason stateful operations like “enter” and “exit” are problematic). The filter “ENTER” determines an event is outside the AOI (so ENTER == FALSE) and the event is discarded. We don’t care that the filter discarded the event in this case because nothing interesting happened (we’re not entering an AOI). But when the next event intersects the AOI and its previous track point was just outside, the filter “ENTER” determines ENTER == TRUE and passes just the one event along.
What we have to understand is that the “Tag on Enter” GeoTagger, at this point, has never seen an event record with this track identifier. The “First Event Triggers Enter” property (a Global Settings property) allows the GeoTagger to evaluate ENTER == TRUE. So we get the tagged event we expect. The same exact evaluation is performed when the event record enters the overlapping area for the first time:
The weirdness starts when the track point is first observed exiting the geofence “Hippo”. The GeoTagger output has a null value in the geofence’s name, even though the Filter determined that an exit has occurred. Why? Because the “Tag on Exit” GeoTagger never saw an event record inside “Hippo” and the global setting “First Event Triggers Exit” default to False.
The EXIT filter saw the previous event, inside, and was therefore able to determine EXIT = TRUE … but all the previous events which were not “exiting” were discarded by the filter so the GeoTagger never saw them. The GeoTagger therefore evaluates EXIT == FALSE and places a null value into the event record’s field as the name of any geofence the event has found to have exited.
When the event moves outside “Campus” the “Tag on Exit” GeoTagger has seen an event record inside “Campus” … when it was just exiting “Hippo” … so it is happy enough to evaluate EXIT == TRUE and enrich the event with the name of the geofence the event record was last observed inside and is now outside.
The real weirdness starts when you run the same eight track points through the GeoEvent Service. This time the “Enter” branch at the top seems able to determine that the event is entering something but cannot name the geofence being entered.
This is again explained if we recognize that we have not done anything that would clear either the ENTER Filter’s cache or the “Tag on Enter” GeoTagger’s cache (like republishing the GeoEvent Service). The “Tag on Enter” GeoTagger has exactly two observations; event record locations inside “Hippo” and inside both “Hippo” and “Campus” when the event records entered those areas for the first time during the last iteration. All of the other received event records were discarded when the ENTER filter determined “not entering”.
So as far as the “Tag on Enter” GeoTagger is concerned, the event is still inside the area “Hippo” when the second report for the second iteration is received. The GeoTagger determines ENTER == FALSE because it has seen records with this track identifier before, so the “First Event Triggers Enter” property does not apply.
Focusing, then, on the last two outputs for the second iteration … analytics for exiting are on a completely separate branch of the GeoEvent Service. That last time the “Tag on Exit” GeoTagger saw a track point from this stream was when it had just exited both geofences and was disjoint all geofences. So when it gets the next “exiting” event (the 6th in the series of eight) it determine EXIT == FALSE because it has not observed the event inside at any point between its last observation and this observation. Therefore the second-to-last message output (again) has a null for the geofence name. But when the event finally exits the two geofences for the last time the “Tag on Exit” GeoTagger has seen the event inside “Campus” so it’s at least able to tag that geofence’s name into the exiting event record.
GeoTagger-Filter Pattern
To fix this, you need to reverse the order of the GeoTagger and filter.
The GeoTagger will capture the name of the yard that was entered/exited (and a null value if the truck is not entering/exiting a yard). The filter will remove any events that have null enter/exit information. Computationally, this pattern has the same number of initial spatial operations (to perform the enters/exits operation), but substitutes the second spatial operation for a simple null attribute check.
Cached Spatial Operations + NULL
As you might expect, the cached spatial operators are reliant on continuous good data. Unfortunately some data feeds are not always accomodating. For example, if you have a data feed that occaisionally provides a NULL geometry, then this NULL will be cached. What this actually means is that the last known location for the event's TRACK_ID will be removed and nothing will take its place. So the spatial operation will think it has never seen that TRACK_ID before. This will cause the spatial operator to rely on the global settings to determine what to do with the next valid location for that TRACK_ID.
Additional Discussions
For some additional discussions of the Enter/Exit operations, please see RJ Sunderman's responses to the following conversations:
Geotagger processor gives all geofences with exit option
Cached Operation Settings
Because GeoEvent must maintain a cache of events to determine the condition of some spatial operators, they are subject to the global settings related to caching. A good discussion of this can be found at the following links:
GeoEvent Documentation
Managing global settings—Administer(10.7.1) | ArcGIS Enterprise (see "Geofence Manager Settings")
The following blog
https://community.esri.com/community/gis/enterprise-gis/geoevent/blog/2016/10/26/using-a-geotagger-p... by Chris Beyett