How to get one single entry message and one single exit message once a ship enters in a geofence area

Question

Currently we are working  with GeoEvent Processor 10.3.1 (no patches installed) and want to receive one single enter message when a ship enters into a genfencing area, and one single exit message when a ship exits a geofencing area.

To receive the single enter message, we use the following geoevent service. This won't work until we add a filter with condition GeoTags != null after GeoTagger AtlanticGeotagger. So, ENTER ANY works as expected --- Only one enter message is received once a ship enters into a geofence area.

We are trying to make EXIT ANY work in a similar way. However, it seems that EXIT ANY has never worked as expected. I have studies the related problems in GeoNET, like https://community.esri.com/thread/103138. We are sure the TRACK_ID is there in GeoEvent Definition (otherwise, ENTER ANY won't work either!), and the "First GeoEvent triggers Enter" is set to false.

My question is: Without using Incident Detector Processor, is there a way to make EXIT ANY work in a way similar to the above settings?

JiehuaYi · Answer

With RJ's help, the final solution in this case should be:

" Stop your GeoEvent Windows service, locate the file com.esri.ges.manager.servicemanager.cfg (beneath …\ArcGIS\Server\GeoEvent\etc) and edit the file to change the maxCacheSize from its default 1000 to 3000.  Then restart your GeoEvent Windows service."

With this change, we are able to see the single Enter message and single Exit message. That is good. However, not all the ships enter and exit info are caught. The cache size maybe need to be increased more.

From the system performance point of view, we have to keep only Enter message and don't setup for EXIT ANY.

JiehuaYi · Answer

There was a typo in the question: the "First GeoEvent triggers Enter" is set to false. Should be the "First GeoEvent triggers Exit" is set to false.

The question has been answered by RJ:

Something I would like to cover, before exploring your use case, are reasons why an existing GeoFence might not be considered by a filter expression. When importing GeoFences (or synchronizing GeoFences) there are a couple of important properties to recognize:

*  Active Field
*  Time Extent Start
*  Time Extent End

The default for Active Field is (Always Active).

Time Extent Start and Time Extent End are not required; they default with no specified value.

These are important because they control which GeoFences will be excluded from the set of candidate GeoFences before a filter expression is evaluated. Let’s say you receive and event, with a TRACK_ID “AA-1234” whose Geometry is a point. The event arrives at a filter whose expression refers to a set of GeoFences which match a regular expression. The first thing GeoEvent will do is exclude / remove from the set of candidate GeoFences any GeoFences whose ACTIVE state is FALSE. It will then exclude / remove any GeoFences whose temporal extent does not include the date/time associated with the event being processed. (The temporal extent is determined using the Time Extent Start and Time Extent End properties of each GeoFence. You can think of these as setting an “effective from” and “effective until” time range for each GeoFence.)

When I mention the “date/time associated with the event being processed”:

*     TRACK_ID and GEOMETRY are probably the two most important tags you will use.
*     Another important tag is TIME_START.
*     If an event’s GeoEvent Definition includes a field tagged TIME_START, that is the date/time processors will associate with an event.
*     If there is no field tagged TIME_START, generally a processor (or filter) will use the system time the event was received.

This can be important when simulating event data. Often the attributes in the records we simulate have date/time values which are old, sometimes years old. If I simulate a set of events whose date/time values are back in 2014, and I tag one of the event’s attribute fields with TIME_START, it is unlikely that the event’s date/time will intersect a set of GeoFences whose Time Extent Start and Time Extent End have been set to date/time values sometime in the current year.

If you have kept the defaults for the three properties I’ve described above, then there’s not much to further you need to consider. All of your GeoFences will be (Always Active) – and with no temporal values specified – all GeoFences will be considered effective from the beginning-of-time until the end-of-time (meaning they will always temporally intersect a given event’s date/time).

Let’s consider a couple of Global Properties which can affect how the stateful operations ENTER and EXIT are evaluated. You mention, in your question below, that you’ve set First GeoEvent triggers Enter to False (even though your screenshot of the Configure Global Settings page shows the properties with their default values).  I’m assuming that if you changed either of these system property values you did so deliberately.

The GeoEvent product properties First GeoEvent triggers Enter and First GeoEvent triggers Exit are intended to allow users to configure the evaluation of spatial relationships between an event’s geometry and a GeoFence when the system has only one event to work with (for a given TRACK_ID). This condition typically follows a system restart when there is no cache of prior positions for a given TRACK_ID. The default values for these properties are:

*  First GeoEvent triggers Enter true
*  First GeoEvent triggers Exit false

The reason for these defaults is that we probably do want to evaluate the very first reported position associated with a particular vessel’s TRACK_ID inside a GeoFence as having “entered” the GeoFence even if we have not previously observed a position for that vessel outside of the GeoFence. But we likely do not want to be told – every time the GeoEvent product is restarted or the server machine is rebooted – that a vessel has “exited” GeoFences that it is not currently inside. More likely we want to first observe a position (associated with a particular vessel’s TRACK_ID) inside a GeoFence before sending a notification that the vessel has exited that GeoFence.

Let’s say that I have established five static polygon GeoFences (we’ll consider dynamic GeoFences later…) :

I can publish the following simple GeoEvent Service with a GeoTagger whose spatial operation is ENTER ANY :

I then send the event illustrated to the right of the GeoEvent Service and allow the input to construct a Geomtery for me from the specified latitude and longitude values. This is the very first event ever received with the TRACK_ID “AA-1234” … so there is no prior event in any sort of cache to which GeoEvent might be able to refer.

Because the First GeoEvent triggers Enter system property has been left as its default True the event I get logged in my system file output looks like:

Let’s say that I then reconfigure the GeoTagger processor so that its spatial operation is EXIT ANY and change the TRACK_ID of the event being received to a value GeoEvent has not yet encountered. When I post a second event whose coordinates are outside all of the established GeoFences, because the First GeoEvent triggers Exit system property has been left as its default False the event I get logged in my system file output looks like:

Notice that the GeoTagger still appends an attribute field ‘GeoTags’ but because the system has never encountered an event “BB-3456” which was inside any of the candidate GeoFences, and First GeoEvent triggers Exit is False, the EXIT ANY condition evaluates to FALSE. The GeoTagger has no named GeoFence which the processed event has “exited”, so the value of its GeoTags attribute is assigned a JSON null.

Looking at the GeoEvent Service you illustrated, I would recommend not placing a filter prior to the GeoTagger processor. Think of a GeoTagger as a special combination of a Filter and the more generic Field Enricher processor. A GeoTagger will take any event it receives, and if the Geometry associated with that event shares the specified spatial relationship with one (or more) existing, active, temporally relevant GeoFence(s) the processor will enrich the event with the name(s) of those GeoFence(s). Otherwise the GeoTagger will enrich the event with an attribute whose value is null (which is itself information you might want to act upon).

You’ve indicated that you want your GeoEvent Service to generate a single e-mail notification when a vessel enters an area modeled as a polygon GeoFence, and a second single e-mail notification when a ship exits a GeoFence. I’ll assume that the GeoFence areas do not overlap and that if a second (or later) vessel position report is simultaneously outside one GeoFence (having left an area) and inside a different GeoFence (having entered an adjacent or nearby area) that it is acceptable to receive separate near simultaneous e-mail messages that the vessel has exited “Area A” and has entered “Area B”. (Note that we cannot guarantee the order of message delivery, so you might get the “exit” email before you get the “enter” email…)

I would recommend resetting the First GeoEvent triggers Enter and First GeoEvent triggers Exit product properties to their default values (to guard against unwanted e-mail alerts when GeoEvent is restarted). Knowing that an EXITS ANY condition will not evaluate True for an polygon GeoFence unless a previous position for the vessel’s TRACK_ID was observed inside that GeoFence, I would recommend publishing a GeoEvent Service like the following which will use a pair of GeoTagger processors, followed by filters which discard events whose GeoTags attribute value is null, so that you send only events of interest to a particular e-mail notification output.

If I HTTP/POST three events in the following order:

[{

"TrackID":"6a0798fa-b526",

"Longitude":-111.013196,

"Latitude":32.004278

}]

[{

"TrackID":"6a0798fa-b526",

"Longitude":-111.033795,

"Latitude":31.936708

}]

[{

"TrackID":"6a0798fa-b526",

"Longitude":-110.961698,

"Latitude":31.950109

}]

Here’s what my two output log files look like – note the values of the timestamps:

*      Entry “GF-Alpha”             1471046197 seconds
*      Exit “GF-Alpha”                 1471046308 seconds  (~48 seconds later)
*     Entry “GF-Beta”                                1471046655 seconds  (~48 seconds later)

--- ENTRY LOG ---                                                                             --- EXIT LOG ---

Now, I mentioned earlier that we would consider dynamic GeoFences later.  Something you should recognize about the stateful operations ENTER and EXIT is that the GeoFences you intend to use to test spatial relationships with events you receive must exist. If an event is received whose Geometry would have intersected a GeoFence (if one existed) and a GeoFence is then created … the event has not technically “entered” the area because it was not first observed outside the area. When the event’s location moves so that it no longer intersects the area you do not get an EXIT because, again, the event never technically “entered” the area (the GeoFence did not exist when the original event position was received).

If you are synchronizing your GeoFences or doing anything which might remove / refresh the set of GeoFences registered with GeoEvent – and you are receiving and processing events at the same time – you should be prepared that stateful event processing might produce unexpected results. The ENTER and EXIT operations are stateful and rather strict in their definitions. If GeoEvent does not first observe an event location outside a GeoFence it will not evaluate a later event as having “entered” the GeoFence. Likewise, if GeoEvent does not first observe an event location inside a GeoFence it will not evaluate a later event as having “exited” the GeoFence.

Loading GeoFences, actively synchronizing GeoFences, changing a GeoFence’s Active True/False state, setting or updating a GeoFence’s Time Extent Start and Time Extent End property values … are all actions which can affect the evaluation of a received event’s spatial relationship against a set of candidate GeoFences. And if GeoEvent does not actually observe an event inside (or outside) a GeoFence it may not evaluate ENTER and EXIT the way you might expect.

I hope this information helps –

RJ