Exit condition behaves differently when used in a spatial Filter than when used in an Incident Detector
| This article provides additional information and examples for the Spatial Filters help topic. Please refer to the illustrations in the online help topic for details on additional spatial operators you can use when configuring a conditional expression. |
GeoEvent Server allows you to configure conditional expressions for both attribute filters and spatial filters. The Incident Detector is an example of a processor that uses the same conditional expressions as a Filter. The processor is configured with an opening condition specifying when a new incident should be created for monitoring and/or when an existing incident's duration and geometry should be updated. An opening condition is required; the closing condition is optional and if left unspecified will be the logical negation of the opening condition.
When using the spatial conditions 'Enter' and 'Exit' you should be aware of a subtle difference between how the Incident Detector processor behaves vs. how a spatial Filter behaves. A Filter does not change anything about an event record it receives. It allows an event record to pass through the filter as long as the data satisfies the filter's spatial condition.
An Incident Detector processor fundamentally changes both the attribute structure and geometry of the event records it receives. Most solutions configure the processor to emit a point geometry, but this is not the same geometry the processor received. The geometry in event records emitted by the processor has been updated based on the ongoing nature of the incident being monitored. That is why the processor can accept point geometries but output point, multipoint, or polyline geometries.
The criteria used to evaluate an 'Enter' condition or an 'Exit' condition are the same as described in the spatial filter help topic. However, an event record passing through a Filter configured with an 'Exit' condition does not change. The geometry will be located outside the polygon the tracked asset has exited. Incident Detector will update the vertex of the geometry to the last-known position inside the polygon the tracked asset is exiting. Thus an 'Ended' incident will locate the tracked asset at the last position inside the polygon.
Consider the illustrations below. A Filter configured with an 'Enter' condition will allow only the data point labeled 'Enter' to pass through the filter. A separate Filter configured with an 'Exit' condition will allow only the data point labeled 'Exit' to pass through the filter.
An Incident Detector must evaluate both an opening and a closing condition. Looking at the same two tracked assets, an Incident Detector processor will open separate incidents for the first track point inside the area of interest from each tracked asset. The processor will update the duration and geometry of its incident and emit an incident with the status 'Ended' when it sees the tracked asset has exited the area of interest. The last vertex of the geometry updated by the processor will be the last observed position inside the area of interest. This is an attempt to match the reported duration the tracked asset was inside the area with the several observations the processor has of the asset actually inside the area.
The behavior illustrated above is how the Incident Detector has reported incidents based on 'Enter' and 'Exit' spatial criteria for several releases prior to the 11.x release series. Solutions which need to monitor the duration of a condition should use an Incident Detector and watch for incident event records to be emitted with 'Started', 'Ongoing', and 'Ended' status. These solutions should also be aware of the behavior described above, that an 'Ended' incident will report the last-observed location inside an area of interest. A Filter, which does not monitor or report the duration of a condition, will not change any aspect of an event record it receives and will locate the data record at its actual last-observed location outside an area of interest.
