GeoEvent - Not registering already existing features

CamiJista — Wed, 19 Dec 2018 11:38:46 GMT

Hi,

I have three feature layers I have Incorporated into GeoEvent services.

1) Point layer called "ex1"

2) Point layer called "ex2"

3) Polygon layer called "buffer"

In one geoevent service I create a buffer around points in ex1 when a attribute value is changed to "true". This creates buffers only around ex1 points with value "true".

These buffers are created in the polygon layer "buffer" and features in this feature layer are imported as geofences with a synchronization rule (1 second interval).

Scenario:

A point in ex1 and a point in ex2 exists already. The value in the ex1 point is changed to true, and a buffer is automatically created. Thereafter I am trying to filter the points based on a spatial filter that defines whether the ex2 point is inside any buffer polygons - filter: "ex2 GEOMETRY INSIDE ANY buffer-geofence/.*"

Then, a field calculator is applied to the geoevents from ex2 which are inside any of the buffer geofences.

However, the service does not register already existing points from ex2, even though I have "Get Incremental Updates" set to "false" which should (as I have understood) poll all features with refresh interval of 10 seconds. So the calculation is only applied if I place a new point inside the buffer polygon.

Regards,

Cami

RJ Sunderman‌

Re: GeoEvent - Not registering already existing features

RJSunderman — Thu, 10 Jan 2019 03:45:54 GMT

Hello Cami –

There are a few things I might suggest you try as you work to troubleshoot your issue:

Reduce your geofence synchronization rule's polling frequency. Try setting the synchronization to run once every 60 seconds rather than once every second.

It’s understandable that you want the polygon buffers created around designated points to be imported as geofences as quickly as possible so that polling on your ex2 feature dataset can take immediate advantage of the new geofences.

A frequency of 1 second is too aggressive for geofence synchronization however. The synchronization rule has a simple timer and, every time the timer expires, a REST request is made against the feature service to retrieve its polygon feature records and import them to update the GeoEvent Server catalog of registered geofences. These requests can be relatively expensive and depending on your network, your database server, and other factors it may realistically take longer than 1000 milliseconds to retrieve the records, update the geofence catalog, and advise the various spatial processors in any GeoEvent Services you have configured that the geofence cache has been updated. (Individual processors cache some of the information about newly registered geofences so that they don’t have to each interact with the geofence catalog every time an event record is received by the processor for processing. This "chatter" between the geofence catalog and your GeoEvent Services tends not to take a lot of time, but it does take some non-zero amount of time.)

When asserting the geofence synchronization changes, watch your system clock and try to click the ‘Synchronize’ button more-or-less as your system clock advances to the next whole minute.

I’ve found that, when debugging, it helps to know when the geofence synchronization rule is firing. Since this is an asynchronous timer and the GeoEvent Manager doesn’t provide you with any visual indication that the synchronization’s timer is about to expire and a new request is about to be made to update geofences, if I set the synchronization interval to 60 seconds and start the timer (by clicking ‘Synchronize’) just as my system clock is advancing from 57, 58, 59, to 60 … I have a pretty good idea of when synchronizations will occur.

You can then refresh your web page displaying known geofences and check to see if in fact new geofences are created/updated when your GeoEvent Service processes feature records polled from the ex1 feature dataset, discovers an attribute value set to “true”, and creates a buffer around the event record's geometry.

As part of your debugging, stop the input which is polling the ex1 feature dataset, wait for a synchronization to occur, then start the input and allow it to conduct exactly one poll.

Something to keep in mind is that this entire workflow has inherent race conditions with asynchronous timers that you don’t have a lot of visibility into or control over. If feature records are polled from the ex1 feature dataset every 20 seconds, there is a chance that the GeoEvent Service is busy creating the buffer and making a request to update polygon features in the buffer feature dataset at the same time the synchronization rule polls to request feature records from that same dataset (to update geofences in the catalog).

If your debugging allows you to know that a synchronization will fire at the top of every minute and you wait perhaps 10 seconds to make sure the synchronization rule has a chance to complete before you start the ex1 input to poll features one time and stop the input after you confirm that all 25 (or whatever) feature records were polled, you can quickly query the buffer feature service yourself via the ArcGIS REST Services Directory to confirm that expected polygon feature records were actually created/updated and wait the balance of the minute for the next geofence synchronization rule to fire so that you can check to see if the polygon features you know to exist were successfully imported as geofences.

Notice that nowhere in this debugging step did I start the input which is polling the ex2 feature dataset. That’s yet another asynchronous timer that you must deal with when debugging. On one hand, I want to make sure that all the pre-requisite steps have occurred successfully – that all ex1 features are being polled, expected buffer polygons are created/updated, and expected geofences established – before I start ex2 polling for additional features to determine if there a spatial coincidence exists between some other set of feature records and synchronized geofences. On the other hand ...

Make sure that the input responsible for polling the ex2 feature dataset actually ingests all of the feature records exposed by that feature service.

This was the heart of your question. It’s easy to focus on expected field calculations which are not occurring as you expect … because a filter configured to identify GEOMETRY INSIDE ANY buffer/.* is not providing any event records to a Field Calculator … even when you are reasonable sure geofences the filter should be using exist.

Regardless of whether the pre-requisite steps above have occurred you should be able to start the input responsible for polling the ex2 feature dataset and confirm that every 10 seconds (or whatever) the input actually polls all feature records exposed by that feature service. This should happen regardless of whether the ex1 input is running or stopped or whether the synchronization rule is updating geofences in the geofence catalog the way you expect.

You are correct that if the input is configured with ‘Get Incremental Updates’ set to ‘No’ and the ‘Query Definition’ beneath advanced has its default ‘1=1’ then all feature records in the feature dataset should be polled by the input every polling interval for processing.

You can use the event counter on the GeoEvent Manager to confirm the number of event records adapted by the ex2 input and even create an output to log the event records created by the input as CSV Text or JSON to a system file immediately after the input before they are sent to a spatial filter or other processor. You want to determine that the input is indeed polling feature records from ex2 as you expect and that you can examine the data for these event records in a system *.json or *.txt file before you worry too much about what processing you want to perform on these feature records.

Make sure your geofences do not have an associated ‘start time’ or ‘end time’.

This is an easy thing to overlook. As you debug to confirm that geofences are being created from the buffer feature records, hover over the geofences in GeoEvent Manager’s list. Make sure the start time and end time field are empty/blank. Even if an event record’s geometry intersects a geofence spatially if the date/time of the event record does not intersect the geofence temporally your ex2 event records will not pass through your filter.

Think of it like this – an event record must be proven to intersect (or fall inside) a geofence for the expression GEOMETRY INSIDE ANY buffer/.* to return TRUE. If the filter cannot find any geofence whose start/end time range intersects the date/time of the event record being tested, the event record’s location / geometry does not matter. There are no temporally relevant geofences, so it cannot be proven that the event record’s geometry is inside any particular geofence, and therefore no event records pass through the filter.

I encourage you to open a support incident with Esri Technical Support so that an analyst can work with you to examine your configured input(s), GeoEvent Services, and geofence synchronization. There's potentially more to the workflow you've described that is apparent on the surface. I hope the information above is helpful in finding the problem.

Best Regards –
RJ

topic Re: GeoEvent - Not registering already existing features in ArcGIS GeoEvent Server Questions

GeoEvent - Not registering already existing features

Re: GeoEvent - Not registering already existing features