GeoTagger configured with an Exit Any condition is not identifying event records exiting a geofence
-------------------------------------------------
Release: GeoEvent Server 11.1
Processor: GeoTagger
-------------------------------------------------
What's wrong with the GeoEvent Service below?
Placing any Filter, but especially a spatial filter configured with an Enter or Exit condition, in front of a processor configured to determine Enter or Exit can produce unexpected results if the filter discards an event record the processor needs in order to correctly evaluate its conditional.
Suppose we have two geofences, Hotel_028 and Indigo_045 as illustrated below.
Two locations of a trackable asset, the point locations #1 and #2 on the map, are received and processed through the GeoEvent Service illustrated above. The intent is to capture information about when the vehicle enters and exits either of the geofences. The vehicle's TRACK_ID has never before been reported, so the filters and processors are observing the vehicle's locations for the first time.
Here's the problem:
- Given that the vehicle's TRACK_ID has never before been observed the default behavior for geofence entry "First GeoEvent triggers Enter" applies. A Filter or Processor evaluating an Enter condition will recognize that the first reported position inside a geofence qualifies as an entry. The upper event processing branch will log the entry of track point #1 as expected.
- The lower event processing branch will not log an exit because the default for "First GeoEvent triggers Exit" is False. With no prior observations, track point #1 does not satisfy the Exited filter's conditional that a previous event record with the same TRACK_ID was observed "inside" some other geofence, so the filter does not see the event record as exiting an area of interest and discards the event record.
- When the second track point #2 is received, the Exited filter, having previously observed the prior track point inside the geofence Hotel_028, recognizes the exiting condition and passes the event record along. But the processor following the filter has not seen or evaluated the first track point. With no prior observations, track point #2 does not satisfy the GeoTag OnExit GeoTagger processor's conditional, so the processor does not write the name of a geofence from which the track point has exited into the event record it processes.
The fix for this is to rework the event processing on the lower branch to move the filtering operation after the GeoTagger.
Illustrated above I have placed two mutually exclusive attribute filters after the GeoTagger processor. The first filter catches the condition when the processor does not recognize an exiting condition and therefore does not write the name of a geofence into an attribute field named GeoTag. Presumably I want to craft some specific message in this case, so I route the event record through a Field Mapper which places a simple message (as a String) into a field to indicate that the current event record has not exited an area of interest.
The second filter catches the condition when the processor does recognize an exiting condition, because the GeoTag attribute field holds the name of a geofence (its value is not null). Again, I want to craft some specific message for this case, so I route the event record through a Field Mapper to place a simple message into a field to indicate the date/time the current event record exited an area of interest and the name of the area exited.
