The Intersector Processor is used to generate a geometry representing the intersection between a geofence and an event record’s geometry. The event record geometry is considered the base while the geofence is the geometry being evaluated to determine whether an intersection exists.
Examples
The following are example uses of the Intersector Processor:
 The Intersector Processor can be used to determine whether an aircraft’s flight path is actively intersecting nofly zones. Assuming the flight path is a polyline and the nofly zones are polygon geofences, the processor can return which segments of the flight path are currently intersecting the nofly zone areas. Polylines representing the intersecting flight path segments can be visualized in a web map or used to send a notification.
 The processor can be used to determine the intersection of a hurricane with facilities on the ground. Assuming the hurricane is a polygon and the facilities are polygon geofences, the processor can return which facilities are actively being intersected (impacted) by the hurricane. This information can be used to enable realtime situational awareness.
Usage notes
Keep the following in mind when working with the Intersector Processor:
 The intersection between two geometries is generally equal to or less than the geometric dimension of the geometries being considered. For example, if an event record’s associated geometry is a point, even if the specified geofence's geometry is a polyline or polygon, the intersection (assuming one exists) must be a point. If an event record’s associated geometry is a polyline and the specified geofence's geometry is a polygon, the intersection is most likely a line but could also be a point.
 The processor can be configured to either replace the event record's geometry with the discovered intersection or write the intersecting geometry into a new field. Adding a new field to an event record alters the event record's schema, which requires GeoEvent Server to create a new GeoEvent Definition. The new GeoEvent Definition will be managed by GeoEvent Server and deleted if changes are made to the processor or the GeoEvent Service in which the processor is used.
 Choosing to tag the new geometry field as GEOMETRY explicitly tells GeoEvent Server which geometry field should be treated as the event record’s realized geometry for subsequent processing or output.
Parameters
The following are the parameters for the Intersector Processor:
Parameter  Description 

Name 
A descriptive name for the processor used for reference in GeoEvent Manager. 
Processor 
Specifies the processor selected. 
Geometry Field  The name of the geometry field or the GEOMETRY tagged field from the inbound event record that the processor should use to determine whether an intersection exists with the specified geofence. 
Replace Geometry  Specifies whether to replace the current event record geometry with the geometry of the derived intersection with geofences. The default is Yes.

New Geometry Field Name (Conditional)  The name of the new geometry field where the intersection geometry will be stored. The parameter is shown when Replace Geometry is set to No and is hidden when set to Yes. 
Tag the New Geometry Field as Geometry (Conditional)  Specifies whether the new geometry field created by the processor will be tagged as GEOMETRY. The GEOMETRY tag is used by GeoEvent Server to identify the event record’s realized geometry when multiple geometry fields are present. The default is No. The parameter is shown when Replace Geometry is set to No and is hidden when set to Yes. 
New GeoEvent Definition (Conditional)  The name assigned to the new GeoEvent Definition. The new GeoEvent Definition will combine the schema of the inbound event record with the additional new geometry field. The parameter is shown when Replace Geometry is set to No and is hidden when set to Yes. 
Geofence  The category and name of the geofence. The processor uses the geofence geometry to calculate the intersection with the event record geometry. The required format for specifying a geofence is category/name, for example:
Only a single category/name expression is supported as an input. Multiple geofence category/name expressions cannot be concatenated with comma separation. For example, specifying Storms/.*,Facilities/.* to evaluate all named Storm geofences and all named Facilities geofences is not a valid input. Note:.* can be used to denote all categories or all named geofences. For example, Storms/.* will compare the event record geometry to all geofences in the Storms category for an intersection. Similarly, .*/.* will compare the event record geometry to all geofences present in GeoEvent Server regardless of category or name. 
Output Geometry Type  The output geometry type of the intersection between the geofences and the event record geometry. Specifying different output geometry types will produce different types of intersections. For examples of different intersections, see How Intersect works. The default is Highest Geometry Type Dimension of the Intersecting Pair. Available output geometry types include the following:
Note:Geometry type dimension refers to the dimensionality of the shape (point = 0 dimension, polyline = 1 dimension, polygon = 2 dimension). 
Considerations and limitations
There are several considerations to keep in mind when using the Intersector Processor:
 Consider the geometry of the inbound event record when configuring the processor. For example, the intersection of a point event record with a geofence that is a polygon cannot return a polygon as the intersection output geometry type. In this situation, only a point can be returned as the output geometry type due to the dimensionality of the involved geometries.
 Consider replacing the existing event record geometry with the intersection geometry prior to sending the event data to a feature service. Feature services only support one geometry type field and therefore whichever field has not been tagged GEOMETRY will be converted and kept as a string.