Geoevent Processor Geofence Question

IgorBalotsky1 · ‎09-15-2015

Let's say I have an input that has a filter condition that is performing an operation on a Geofence. Is it possible to somehow output the fields of the geofence as well along with the input fields? I have tried adding the Geofence fields to my input geoevent definition but I still can't see them on the output and it does not seem they are getting passed.

A practical example is if let's say I am monitoring firetruck AVL and sending an email if they get inside a fire perimeter - the name of the fire and other useful information is in the touched fire perimeter geofence so how would I get this information? There could be multiple fires so it's not sufficient to just email that a firetruck has left/entered a fire perimeter.

Thanks,

Igor

RJSunderman · ‎09-15-2015

Hello Igor -

Please take a look at the following thread: Re: GeoTagging several fields from one geo fence

GeoFences are intentionally lightweight by design. Typically, geometries from features in a feature service are used to model GeoFences, and when you import (or synchronize) GeoFences the only attributes brought in are a unique name for the GeoFence and a Geometry. You can see this if you log-in to the GeoEvent Administrative API and look at the GeoFences you have loaded.

GeoFences are maintained in-memory, so one concern with including attribute information with every GeoFence is that system RAM requirements will increase significantly. You should think of GeoTagging as a special case of event enrichment combined with spatial filtering. GeoTagging allows an event to be enriched with the name of a GeoFence (and optionally the name of the Category to which the GeoFence belongs) when an event has a spatial relationship with the GeoFence. The GeoFence name is the only attribute available to the GeoTagger.

Following the recommendation in the thread I mention above, if you follow a GeoTagger with a Field Enricher you can have your GeoEvent Service go back to the feature class from which your GeoFences were loaded and, using the GeoFence name the GeoTagger appended to the event as a field to join the event and the feature class, enrich needed attribute information from the feature originally used to model the GeoFence.

I tend to refer to this pattern as a "primary enrichment" (performed by the GeoTagger) followed by a "secondary enrichment" (performed using a Field Enricher). This approach does have a limitation; GeoFences cannot overlap. When they do, the GeoTagger will enrich an event with a comma separated list of GeoFence names ... since you cannot use a comma separated list as a primary key to perform a table join, you cannot conduct the "secondary enrichment". (See threads Field Enricher with Multiple Matches and Overlapping geofences with different attributes).

We are considering an enhancement to allow users to specify, when importing or synchronizing GeoFences, that attributes other than a unique name and Geometry be included in the GeoEvent's catalog of GeoFences, but the enhancement has not been assigned and will likely not be considered until after the 10.4.1 product release.

Hope this information helps -

RJ

View solution in original post

RJSunderman · ‎09-15-2015

Hello Igor -

Please take a look at the following thread: Re: GeoTagging several fields from one geo fence

GeoFences are intentionally lightweight by design. Typically, geometries from features in a feature service are used to model GeoFences, and when you import (or synchronize) GeoFences the only attributes brought in are a unique name for the GeoFence and a Geometry. You can see this if you log-in to the GeoEvent Administrative API and look at the GeoFences you have loaded.

GeoFences are maintained in-memory, so one concern with including attribute information with every GeoFence is that system RAM requirements will increase significantly. You should think of GeoTagging as a special case of event enrichment combined with spatial filtering. GeoTagging allows an event to be enriched with the name of a GeoFence (and optionally the name of the Category to which the GeoFence belongs) when an event has a spatial relationship with the GeoFence. The GeoFence name is the only attribute available to the GeoTagger.

Following the recommendation in the thread I mention above, if you follow a GeoTagger with a Field Enricher you can have your GeoEvent Service go back to the feature class from which your GeoFences were loaded and, using the GeoFence name the GeoTagger appended to the event as a field to join the event and the feature class, enrich needed attribute information from the feature originally used to model the GeoFence.

I tend to refer to this pattern as a "primary enrichment" (performed by the GeoTagger) followed by a "secondary enrichment" (performed using a Field Enricher). This approach does have a limitation; GeoFences cannot overlap. When they do, the GeoTagger will enrich an event with a comma separated list of GeoFence names ... since you cannot use a comma separated list as a primary key to perform a table join, you cannot conduct the "secondary enrichment". (See threads Field Enricher with Multiple Matches and Overlapping geofences with different attributes).

We are considering an enhancement to allow users to specify, when importing or synchronizing GeoFences, that attributes other than a unique name and Geometry be included in the GeoEvent's catalog of GeoFences, but the enhancement has not been assigned and will likely not be considered until after the 10.4.1 product release.

Hope this information helps -

RJ