keep attributes of signal to the alert feature class

Question

Hello,
I have an input of some data streaming set up, and i lead it through some incident detectors to an alert feature service. I need to keep some values from the data and store them in the alerts along with the other default alert fields. I tried to use a field mapper but it does not seem to work..
Is there any clue on how to achieve this?

Thank you in advance,

Elias

MarcGraham1 · Answer

Hi,

I have created an idea on the ArcGIS Ideas site to get incidents to return the name of the geofence they are related to here: https://community.esri.com/ideas/12395

I think this would be a good enhancement.

Cheers,

Marc

RJ Sunderman

KDeVogelaere · Answer

Great explanation of the Incident Detector behavior, we had a similar problem and ended up replacing our Incident Detector with a Filter and found that checking when GEOMETRY points are INSIDE a Weather polygon GeoFence produced duplicate alerts with every poll refresh of the input points. We switched INSIDE in favor of ENTER GeoFence and added a TRACK_ID tag to one of our key fields in the Input GeoEvent Definition. This helped prevent the duplicate alerts.

See below for a Visual representation:

Kate

RJSunderman · Answer

Hello Elias -

I am not sure that what you are trying to do with the Incident Detector processor is a good fit with the intended use of that type of processor. I would like to include some background I think might be applicable to what you are trying to do. If I am diverging from your need or objective, please help me to focus both what you are trying to accomplish and why.

Assuming that the vessel data being sent into GeoEvent processor is being enriched with an identifier of a GeoFence the vessel is currently INSIDE, and one or more attributes from the GeoFence's original polygon (I think you referred to these as "reasons" a vessel is prohibited from entering an area) ... you want to use an Incident Detector processor to generate an alert which contains the vessel's name / track identifier, prohibited zone identifier, and prohibition reason / regulation?

Do you really need to use an Incident Detector? If you do not need to track and report the duration of the vessel's violation you could filter the vessel GeoEvents for those INSIDE a prohibited area and then select and send information from GeoEvents which survive the filter to a notification output (Email, SMS Text, or update an "alerts" feature service). A second filter identifying vessel GeoEvents NOT INSIDE a prohibited area could then update a feature service with all of the vessels currently in compliance.

An Incident Detector is intended to act as a monitor. The events output from this type of processor are derived from the events it receives. The only information an incident is supposed to share with its originating event is the TRACK_ID.  An Incident Detector is primary used is to create an incident, track the incident,  and the incident's duration -- independent of the GeoEvent whose attributes or spatial proximity triggered the incident.

An expected workflow might be something like:* A vessel enters a prohibited area
* A GeoTagger processor tags the event with the name of the zone the vessel is violating
* A Field Enricher processor enriches the event with the reason the zone is not to be entered
* An Incident Detector processor generates and begins tracking duration of the incursion
* A notification is output to inform an analyst that a violation has occurred.

An analyst, receiving an Email, SMS Text, or observing an "alert" in a table widget or map display within an application would be expected to take note of the TRACK_ID in the incident and query to locate the related feature. The analyst would use a client application identify the vessel which has entered the prohibited area and open that feature's attribute table to identify the reason behind the violation.

Because the GeoEvents containing the vessel information and those containing the incident information are separate events, they cannot be mapped or joined together within a GeoEvent Service. Both events would need to be persisted out to a table (e.g. a feature class) which could then be polled as part of a second GeoEvent Service to enrich the incident with data from the vessel. But doing so creates a race condition ... there is no guarantee that the two different GeoEvents will be written out to their tables such that a second GeoEvent Service will have the features it needs to do its job at any given instant.

If you truly do need an Incident Detector processor, because you do need to track the duration of a violation - or need to leverage something else the Incident Detector is providing you - perhaps you could look at using a Make Query Table or similar tool from the Data Management toolbox (outside of GeoEvent processor) to handle the necessary join of a vessel feature with its corresponding incident.

- RJ