Processors

Processors are a component of a GeoEvent Service that perform specific actions on the GeoEvents, such as identification or enrichment as GeoEvents are routed from inputs to outputs.

All processors, when created, must be assigned a name. The name is case-sensitive and will be used to uniquely identify the processor in a GeoEvent Service. The type of processor being created is specified using the Processor drop-down, as illustrated below.

GeoEvent Server includes the following processors:

Buffer Creator

The Buffer Creator Processor can be used to dynamically create a buffer around a GeoEvent's geometry. This processor requires the field containing the GeoEvent's geometry to be specified. The field name or a tag applied to a field within a GeoEvent Definition can be used to identify the geometry field.

This processor can be configured to either replace the GeoEvent's geometry with the computed buffer or place the computed buffer into a new field. Altering a GeoEvent's schema by adding a new field 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 participates.

When creating a geometric buffer, you must specify the linear units and a numeric distance for the buffer. GeoEvent Serverdoes not support buffers measured in angular units (for example, decimal degrees). The Buffer Creator interface provides a list with common linear units such as Feet, Yard, Meter, Kilometer, and Nautical Mile. GeoEvent Server administrators can configure the units for the processor through the GeoEvent Manager. The buffer distance is specified as a positive integer value.

When computing a buffer, it is sometimes necessary to specify a projection other than the one associated with the geometry being buffered. For example, point locations that received in the WGS84 coordinate system cannot be buffered in that same coordinate system. A projected coordinate system, roughly centered within the expected extent of the expected event geometries, should be chosen instead. When specifying a projection other than the one associated with the GeoEvent geometries being received, use the numeric Well Known Identifier (WKID) of the most appropriate projection.

For more information on the Buffer Creator Processor, see the Introduction to GeoEvent Server tutorial available from GeoEvent Server tutorials.

Convex Hull Creator

Use a Convex Hull Creator Processor when you need to dynamically produce a polygon representing the smallest region or area enclosing a GeoEvent's geometry. Conceptually, a convex hull is the shape a rubber band would take if it were stretched around a GeoEvent's geometry.

• Given a point, this processor will produce an equivalent point.
• Given a line with two vertices, this processor will produce an equivalent line.
• Given a simple convex polygon or envelope, this processor will produce an equivalent geometry.
• Otherwise, the processor will produce the smallest convex polygon that contains the GeoEvent's geometry.

Convex Hull Creator requires that the field containing the GeoEvent's geometry be specified. The field name or a tag applied to a field in a GeoEvent Definition can be used to identify the geometry field.

Convex Hull Creator can be configured to either replace the GeoEvent's geometry with the produced convex hull or place the convex hull into a new geometry field. Altering a GeoEvent's schema by adding a new field requires GeoEvent Server 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 participates.

For more information on the Convex Hull Creator Processor, see the Introduction to GeoEvent Server tutorial available from GeoEvent Server tutorials.

Difference Creator

Use a Difference Creator Processor when you need to determine the intersection between a GeoEvent's geometry and a geofence and then clip or remove the portion of the geofence that intersects the GeoEvent's geometry.

Difference Creator requires two discrete geometries be specified. You cannot, for example, use a regular expression to specify several different geofences and remove the intersecting portions of each geofence from the GeoEvent's geometry. The processor also requires that the dimensionality of the geofence be equal to or greater than that of the GeoEvent's geometry—you cannot, for example, clip or subtract a point from a polyline (or a polyline from a polygon).

Difference Creator can be configured to replace the GeoEvent's geometry with the computed difference of the two geometries or place the difference into a new geometry field. Altering a GeoEvent's schema by adding a new field requires GeoEvent Server 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 participates.

For more information on the Difference Creator Processor, see the Introduction to GeoEvent Server tutorial available from GeoEvent Server tutorials.

Envelope Creator

The Envelope Creator Processor can be used to produce a simple rectangular envelope enclosing a GeoEvent's geometry. Contrast this with a Convex Hull Creator Processor, which produces a polygon representing the smallest area enclosing a GeoEvent's geometry—a convex hull is not always rectangular, whereas an envelope is always rectangular.

• Given a point, this processor will produce an equivalent point.
• Given a multipoint or line with two or more vertices with varying latitude, this processor will produce an envelope. A valid envelope cannot be produced if all of a geometry's vertices share the same latitude.

Envelope Creator requires the GeoEvent field containing the geometry be specified. The field name or a tag applied to a field in a GeoEvent Definition can be used to identify the geometry field.

Envelope Creator can be configured to either replace the GeoEvent's geometry with the created envelope or place the envelope into a new geometry field. Altering the GeoEvent's schema by adding a new field 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 participates.

For more information on the Envelope Creator Processor, see the Introduction to GeoEvent Server tutorial available from GeoEvent Server tutorials.

Field Calculator

The Field Calculator Processor can be used to compute a value. The processor evaluates an expression to produce the needed value. The expression can include literal strings, numeric constants, and event data taken from named fields in the GeoEvent being processed. The calculated value can be written into an existing field, overwriting the data currently in that field, or it can be written into a new field created by the processor.

The Field Calculator is a versatile processor. Relatively constant expressions such as Distance * 0.3048 can be used to calculate an equivalent distance in meters given a distance expressed in feet. The processor also supports a variety of Java String functions such as the expression replaceAll(Description, 'foo', 'bar'), for example, which can be used to replace all instances of the substring "foo" with the substring "bar" in the description field of each GeoEvent. The processor also supports a number of mathematical functions. For example, you can identify which of two GeoEvent fields contains a larger value using max(Time1, Time2) or generate a random number using random().

Some points to consider when using Field Calculator:

• Expressions can be mathematical or lexical (based on strings, rather than numerical values).
• When working with literal strings, be sure to enclose them in single quotes: 'Cat' + ' ' + 'Dog'.
• The processor will output a null value if a type conversion fails or the expression cannot be evaluated.
• Operands in an expression can be literal field names or tags applied to fields in a GeoEvent Definition. For example, the expression Odom1 + Odom2 could be used to add values in the Odom1 and Odom2 fields to produce a simple sum. If the Odom1 field was tagged MILEAGEA and the Odom2 field was tagged MILEAGEB, the expression MILEAGEA + MILEAGEB could be used.
• A good-faith effort will be made to handle data of different types within an expression. For example, 325 + 0.125, will be converted to an equivalent 325.0 + 0.125. If the specified output field expects a long integer value, the calculated double value will be truncated.
• Watch for overflow when creating expressions. For example, each term in the expression 60 * 60 * 80 * 10000 is a short integer, but the result exceeds the 32-bit range of a normal integer. Expressing each term as a double value like 60.0 * 60.0 * 80.0 * 10000.0 avoids this issue.
• Writing a computed value to a new field alters a GeoEvent's schema, which requires GeoEvent Server to create a new GeoEvent Definition. When using this processor to create new fields, a field name and data type must be specified. A name for the GeoEvent Definition can be specified as well as an optional tag, which, if specified, will be applied to the new field in the resulting GeoEvent Definition.

The operators and functions supported by the Field Calculator Processor are illustrated below.

Operators and functions supported by Field Calculator

Operation	Operator	Example
Addition	+	Odom1 + Odom2 Expression adds the numeric values from the fields Odom1 and Odom2 to produce a simple summation. String concatenation (for example, 'Hello' + 'World') is also supported.
Subtraction	-	VALUEA - VALUEB Expression subtracts the numeric values found in the fields tagged VALUEA and VALUEB to produce a simple difference. Unlike addition, which supports string concatenation, you cannot use subtraction to calculate the difference between two strings.
Multiplication	*	Altitude * 0.3048 Expression multiplies the numeric value in the field named Altitude and the constant 0.3048 to produce a simple product (in this case, converting a value in feet to an equivalent value in meters).
Division	/	Distance / 1.609344 Expression divides the numeric value in the field named Distance by the constant 1.609344 to produce a simple quotient (converting a value in kilometers to an equivalent value in miles).
Modulus	%	VALUEA % VALUEB Expression divides the numeric value in the field tagged VALUEA by the numeric value in the field tagged VALUEB and returns the remainder as a double value.
Logical AND	&&	Flag1 && Flag2 Expression performs a logical AND on the Boolean values from the fields named Flag1 and Flag2 to produce a Boolean result. Input fields must be of type Boolean. Literal strings (for example, TRUE) and constant values (for example, 1) in an expression will not be converted to an equivalent Boolean as part of the evaluation.
Logical OR	||	Flag1 || Flag2 Expression performs a logical OR on the Boolean values from the fields named Flag1 and Flag2 to produce a Boolean result.
Logical NOT	!	!(Flag1) Expression performs a logical negation on the Boolean value from the field Flag1 to produce a Boolean result. Supports nested expressions such as !(Flag1 && Flag2).
Greater-Than	>	Altitude > 12500 Expression performs a logical evaluation to determine if the value in the field named Altitude is greater than the specified constant (result is a Boolean value).
Greater-or-Equal	>=	Altitude >= 12500 Expression performs a logical evaluation to determine if the value in the field named Altitude is greater than or equal to the specified constant (result is a Boolean value).
Less-Than	<	Altitude < 1500 Expression performs a logical evaluation to determine if the value in the field named Altitude is less than the specified constant (result is a Boolean value).
Less-or-Equal	<=	Altitude <= 1500 Expression performs a logical evaluation to determine if the value in the field named Altitude is less than or equal to the specified constant (result is a Boolean value).
Equality	==	VALUEA == VALUEB Expression performs a logical evaluation to determine if the values found in the fields tagged VALUEA and VALUEB are equivalent (result is a Boolean value). Equivalency is only supported for numeric types with the initial product release (10.2.0).
Inequality	!=	VALUEA != VALUEB Expression performs a logical evaluation to determine if the values found in the fields tagged VALUEA and VALUEB are not equal (result is a Boolean value). Inequality is only supported for numeric types with the initial product release (10.2.0).

Note:

The Field Calculator Processor will attempt to auto-convert values when presented with mixed types. For example, the expression 10.0 + 5 would auto-convert to handle the summation as the addition of two floating point values. Mixing numeric values and string values such as codeValue + 'SomeString' where codeValue is a numeric value will produce an unspecified result. The correct approach would be to explicitly convert codeValue to a string using a string function such as valueOf(object) described below.

Note:

The Field Calculator Processor equality and inequality operators should not be applied directly to floating point values. To correctly compare if two decimal values are equal, you must first scale the values, round the values to long integers, and then compare the long integer values.

• Do not compare MyFloat1 == MyFloat2.
• Instead, compare round(MyFloat1*1000) == round(MyFloat2*1000).

The Field Calculator Processor includes functions that mirror those found in java.lang.Math. For a complete technical specification and list of functions, refer to the Java developer documentation. A summary of the most popular functions is included below.

Constants for Field Calculator

Function	Description
E()	Returns Euler's number (e) raised to the power of the specified double value
PI()	Returns a double representation of pi (the ratio of a circle's circumference to its diameter)

Time functions for Field Calculator

Function	Description
currentTime()	Returns the local server's current system time as an epoch long in milliseconds
receivedTime()	Returns the timestamp of when the input connector created the event

Common functions for Field Calculator

Function	Description
abs(value)	Returns the absolute value of the argument
ceil(double)	Returns the ceiling (next greatest integer) of the specified double value
currentTime()	Returns the system's current date/time as a long integer (epoch milliseconds)
floor(double)	Returns the floor (next smallest integer) of the specified double value
hypot(double x, double y)	Returns sqrt((x*x) + (y*y)) without intermediate overflow or underflow
max(value a, value b)	Returns the greater of two specified argument values
min(value a, value b)	Returns the smaller of two specified argument values
random()	Returns a double value greater than or equal to 0.0 and less than 1.0
receivedTime()	Retrieves the date/time the event record was received by an input connector as a long integer (epoch milliseconds)
round(value)	Returns the closest long to the argument (given a double value)

Note:

A Field Calculator Processor will handle numeric type conversions when possible. For example, when providing different numeric types to a function (for example, max(3.14159,25)), the values will be cast to comparable types (int, float, or double) in order to perform the comparison. The processor will also cast calculated values when writing the values to an event's attribute field (for example, 6 + 7 will be written as 13.0 when the event's field is of type double).

Exponentials for Field Calculator

Function	Description
sqrt(double)	Returns the square root of the specified double value
cbrt(value)	Returns the cube root of the specified double value
exp(double)	Returns Euler's number (e) raised to the power of the specified double value
pow(double, double)	Returns the value of the first argument raised to the power of the second argument

Logarithms for Field Calculator

Function	Description
log(double)	Returns the natural logarithm (base e) of a double value
log10(double)	Returns the base 10 logarithm of a double value

String functions for Field Calculator

Function	Description
For reference, the syntax examples below use the following example input data:
length(string) Returns: integer Example: 'TrackID length: ' + length(TrackID)	Returns the length of the string. Result: "TrackID length: 7"
isEmpty(string) Returns: boolean Example: isEmpty(EmptyStr)	Returns true if the source's length is 0. Result: true
isNull(string) Returns: boolean Example: isNull(NullValue)	Returns true if the source value is null. Result: true
equals(string, string) Returns: boolean Example: equals(TrackID, EmptyStr)	Returns true if the given string attribute values are equivalent. Returns false if the strings are not equivalent; null if values other than strings are provided as input. Result: false
equalsIgnoreCase(string, string) Returns: boolean Example: equalsIgnoreCase(TrackID, toString(TrackNum))	Compares the source string to another string, ignoring differences in case. Returns true if the given string attribute values are equivalent, ignoring case. Returns false if the strings are not equivalent; null if values other than strings are provided as input. Result: false Explanation: "AA-1234" does not equal "1234"
compareTo(string, string) Returns: integer Example: compareTo('ABCXD', 'ABCZD')	Compares two strings lexicographically. Returns the value 0 if the two strings are equal; a negative value if the first string is lexicographically less than the second string; and a value greater than zero if the first string is lexicographically greater than the second. Result: -2 Explanation: int('X') - int('Z') returns -2 because 'X' is two positions less than 'Z' in the alphabet.
compareToIgnoreCase(string, string) Returns: integer Example: compareToIgnoreCase('abcde', 'ABCDE')	Compares two strings lexicographically, ignoring differences in case. Result: 0
startsWith(string, value) Returns: boolean Example: startsWith('Programming', 'Program')	Returns true if the string begins with the specified prefix; false otherwise. The second argument, value, can be a string or integer value which can be implicitly cast to a string. Result: true
endsWith(string, value) Returns: boolean Example: endsWith(TrackID, TrackNum)	Returns true if the string ends with the specified suffix; false otherwise. The second argument, value, can be a string or integer value which can be implicitly cast to a string. Result: true Explanation: "AA-1234" ends with "1234"
indexOf(string, string, startIndex) Returns: integer Example: indexOf('ABCDABCBCA','BC',3)	Returns the first index at which a specified substring is found within a search string, starting at the specified index. For index searching from the beginning of the string, specify the search start at index 0. Result: 5 Explanation: Starting with the character at position 3, the first occurrence of the substring 'BC' is at position 5.
lastIndexOf(string, string, startIndex) Returns: integer Example: lastIndexOf(TrackID,'-',length(TrackID))	Returns the last index at which a specified substring is found within a search string, searching backward from the specified index. For index searching from the end of the string, specify the search start at length(source). Result: 2 Explanation: Starting at the end of the string and searching backward, the substring '-' was found as position 2.
substring(string, intIndexBegin, intIndexEnd) Returns: string Example: substring('ABCDABCXYZABCDABC',7,10)	Returns a substring extracted from the source string as a new string. The substring begins at the specified intIndexBegin and extends to the character at index (intIndexEnd - 1). The third parameter can be expressed as a nested function length(source) or -1 which implies end of string. Result: "XYZ" Explanation: Starting at character index 7 ('X') return the three characters at positions 7, 8, and 9.
concat(string, string) Returns: string Example: concat('Hello', 'World')	Concatenates the specified string to the end of the source string. Result: "HelloWorld"
matches(string, regex) Returns: boolean Example: matches(TrackID, '[A-Z]+[-][0-9]+')	Returns true if the specified regular expression pattern matches the specified string; false otherwise. The regular expression pattern, regex, is specified as a second string. Result: true Explanation: The whole of the TrackID matches the pattern "one or more letters, followed by a dash, followed by one or more numeric digits.
contains(string, substring) Returns: boolean Example: contains(TrackID,'-')	Returns true if the source string contains the specified substring. Result: true Explanation: The TrackID contains a literal '-' somewhere within the string value.
replaceFirst(string, regex, replacement) Returns: string Example: replaceFirst(TrackID,'[0-9]+','nnnnn')	Replaces the first substring matching the specified regular expression pattern with the specified replacement string, returning the result as a new string. Result: "AA-nnnnn" Explanation: The first substring matching the pattern "one or more numeric digits" was replaced with a literal string 'nnnnn'.
replaceAll(string, regex, replacement) Returns: string Example: replaceAll('ABABCABABABD','AB','X')	Replaces each substring of the source string that matches the given regular expression with the given replacement. Returns the resulting string as a new string. Result: "XXCXXXD" Explanation: Every occurrence of the regular expression pattern 'AB' has been replaced with a literal string 'X'.
replace(source, target, replacement) Returns: string Example: replace('2017-12-31','-','/')	Replaces each occurrence of a substring, specified as a literal string, with a specified replacement substring (also specified as a literal string). Returns the resulting string as a new string. Result: " 2017/12/31"
toLowerCase(string) Returns: string Example: TrackID + ' to lower: ' + toLowerCase(TrackID)	Converts all of the characters in the source string to lowercase using the rules of the default locale. Returns the string, converted to lowercase, as a new string. Result: "AA-1234 to lower: aa-1234"
toUpperCase(string) Returns: string Example: TrackID + ' to upper: ' + toUpperCase(TrackID)	Converts all of the characters in the source string to uppercase using the rules of the default locale. Returns the string, converted to uppercase. Result: "AA-1234 to upper: AA-1234" Explanation: In this example, the TrackID alphabetic portion was already upper-case.
trim(string) Returns: string Example:	Returns a copy of the source string, with leading and trailing white space omitted. Result: "GeoEvent Server"
toString(fieldName) Returns: string Example: toString(Geometry) Example: toString(Epoch)	Returns a string representation of the value in the specified event attribute field. These functions are intended to allow string representations of Date and Geometry attributes to be nested within other functions such as substring, so that real-time analytics can extract information from the higher-order data type. Result: "{""x"":32.125,""y"":-117.125,""spatialReference"":{""wkid"":4326}}" Result: "Fri Nov 03 17:07:56 PDT 2017"
valueOf(fieldName) Returns: string Example: valueOf(Geometry) Example: valueOf(Epoch)	Returns a string representation of the value in the specified event attribute field. The toString( ) and valueOf( ) functions wrap identical implementations.

Trigonometric functions for Field Calculator

Function	Description
acos(double)	Returns the arc cosine of a value (returned angle is between 0.0 and pi)
asin(double)	Returns the arc sine of a value (returned angle is between -pi/2 and pi/2)
atan(double)	Returns the arc tangent of a value (returned angle is between -pi/2 and pi/2)
atan2(double y, double x)	Returns the angle theta from the conversion of rectangular coordinates (x, y) to polar coordinates (r, theta)
cos(double)	Returns the trigonometric cosine of an angle
cosh(double)	Returns the hyperbolic cosine of a double value
sin(double)	Returns the trigonometric sine of an angle
sinh(double)	Returns the hyperbolic sine of a double value
tan(double)	Returns the trigonometric tangent of an angle
tanh(double)	Returns the hyperbolic tangent of a double value
toDegrees(double)	Converts an angle measured in radians to an approximate angle in degrees
toRadians(double)	Converts an angle measured in degrees to an approximate angle in radians

Field Calculator (Regular Expression)

The Field Calculator (Regular Expression) Processor can be used to leverage the power of regular expressions to identify a pattern within a target field and extract the substrings from received events. The extracted substrings are either written back to the target field, replacing the field's original value, or written to a new field. This processor does not support the general mathematical, lexical, and logical expressions supported by the Field Calculator Processor above.

Note:

When specifying the Field Name parameter for this processor, do not forget to enclose the field name with ${…}. This is different than the Field Calculator Processor above, which expects GeoEvent field names without encasement.

Note:

The Field Calculator (Regular Expression) Processor does not support back references within the specified regular expression pattern.

Writing a computed value to a new field alters the GeoEvent's schema, which requires the GeoEvent Server to create a new GeoEvent Definition. When using this processor to create new fields, a field name and data type must be specified. A name for the GeoEvent Definition can be specified as well as an optional tag, which, if specified, will be applied to the new field in the resulting GeoEvent Definition.

Field Enricher (Feature Service)

The Field Enricher (Feature Service) Processor can be used to enrich GeoEvents with attribute data from a published feature service's feature layer or nonspatial table. The attributes will be appended as new fields to the GeoEvent being processed. The processor requires a registered ArcGIS Server connection be specified; the service folder, the feature service name, and the target layer within the feature service must all be specified when configuring this processor. The data types for each appended field will be carried over from the enrichment source—they are not specified as part of the processor configuration.

GeoEvent enrichment relies on what database professionals refer to as a table join. You can specify a field name from the feature service's table and the name of the GeoEvent field on which a join can be performed. While the actual field name from the feature service's table must be provided, the GeoEvent field on which the join will be performed can be specified using either the name of the GeoEvent field or a tag applied to a field in the GeoEvent Definition associated with the event being processed.

A comma-separated list of the fields to be included in the enrichment can be constructed using the processor's properties dialog box by selecting fields or typed manually using the keyboard. You can optionally specify the tags GeoEvent Servershould apply to each new field it creates as a second list of comma-separated values.

GeoEvent enrichment alters the GeoEvent'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 participates.

For more information on the Field Enricher (Feature Service) Processor, see the Introduction to GeoEvent Server tutorial available from GeoEvent Server tutorials.

Field Enricher (File)

The Field Enricher (File) Processor can be used to enrich GeoEvents with attribute data contained in a system file rather than from a published feature service. GeoEvent enrichment from a system file requires the system folder containing the file be registered with GeoEvent Server as a data store. Once a registered system folder is specified, the processor can retrieve the enrichment data from a named file.

Note:

When using a text file as the source for enrichment, the file must follow the format illustrated below. Specifically, the first line of the file must identify the field names as comma-separated values. The second line must specify the data type of each field. The file’s data values are entered starting with the third line of the file.

PilotName,PilotPhone,PilotYearsOfService,PilotActive
String,String,Integer,Boolean
Adam Mollenkopf,111-111-1111,4,TRUE
Ryan Elliott,222-222-2222,7,TRUE
Javier Delgadillo,333-333-3333,12,TRUE
Vlad Plechnoy,444-444-4444,10,TRUE
NickBrezovar,555-555-5555,5,TRUE

GeoEvent enrichment relies on what database professionals refer to as a table join. You can specify a field name from the feature service's table and the name of the GeoEvent field on which a join can be performed. While the actual field name from the feature service's table must be provided, the GeoEvent field on which the join will be performed can be specified using either the name of the GeoEvent field or a tag applied to a field in the GeoEvent Definition associated with the event being processed.

A comma-separated list of the fields to be included in the enrichment can be constructed using the processor's properties dialog box by selecting fields or typed manually using the keyboard. You can optionally specify the tags GeoEvent Servershould apply to each new field it creates as a second list of comma-separated values.

GeoEvent enrichment alters the GeoEvent'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 participates.

For more information on the Field Enricher (File) Processor, see the Introduction to GeoEvent Server tutorial available from GeoEvent Server tutorials.

Field Mapper

The Field Mapper Processor can be used to translate (or map) data from one GeoEvent schema to another GeoEvent schema or GeoEvent Definition. Every GeoEvent has an associated GeoEvent Definition that identifies the attribute fields and data types. GeoEvent Definitions can change if they are processed, such as when a GeoEvent is enriched with new fields.

To configure Field Mapper, select a source GeoEvent Definition and a target GeoEvent Definition. Fields from the target GeoEvent Definition appear to the right, with drop-down lists available from the selected source GeoEvent Definition, allowing you to select the appropriate field to map. The data type of each field is displayed to help identify the appropriate mappings for each field.

A GeoEvent Definition appropriate to GeoEvents at one stage of processing might not align with the schema of a published feature service. The GeoEvent will need to be processed by Field Mapper to translate each GeoEvent's schema to match the schema of the target features before a GeoEvent Service can update features in a feature service.

For example, many real-time data streams (especially those providing generic JSON) frequently provide data structures that include groups with subfields or lists with multiple values. Such data structures do not align with feature service schemas whose data structures are flat and expect discrete data types (date, string, integer, and so forth). The primary purpose of Field Mapper is to flatten hierarchical structures and align them with a feature service's schema.

Some other common uses for Field Mapper include the following:

• Since specifying a target GeoEvent Definition establishes the schema of the GeoEvents sent from Field Mapper, the processor can effectively be used to reduce the number of attribute fields routed from an input to an output. You just need to create a GeoEvent Definition with the desired fields and then use Field Mapper to reduce and align GeoEvents received by a GeoEvent Service with the desired output schema.
• Field Mapper can be used to perform some basic data conversions. For example, when a GeoEvent field containing integer data can be converted to a long or double representation of the data value. Numeric values can be converted to create string representations of the data. If Field Mapper is unable to complete a data type conversion, a null value will be written to the mapped field.

Note:

If you are updating features in a published feature service and do not want one or more fields of existing features to be modified, leaving those fields unmapped in Field Mapper will result in null values being written as features are updated. Use Field Reducer (see below) to remove unmapped fields before sending the GeoEvents to an output connector, which is responsible for the feature service update.

Field Reducer

The Field Reducer Processor can be used when you need to remove fields from a GeoEvent. This effectively deletes attribute data from the GeoEvent being processed, allowing a simplified representation of the GeoEvent to be routed for additional processing or sent to an output. When configuring Field Reducer, specify the fields to be removed as a comma-separated list.

Field reduction alters the GeoEvent'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 participates. Lastly, specify a name for the new resulting GeoEvent Definition.

GeoTagger

The GeoTagger Processor can be used to enrich a GeoEvent with the name of an area of interest, also known as a geofence, with which the GeoEvent's geometry has a specified spatial relationship.

GeoTagging is a special case of event enrichment and spatial filtering. For example, you can configure a GeoTagger to append the names of any geofences a GeoEvent's geometry is found to be inside. GeoEvents processed by the GeoTagger will have a field appended to it that contains the names of any geofences in which its geometry is found.

Note:

Geofences must be imported into GeoEvent Server from a feature service prior to configuring a GeoTagger Processor. See Managing geofences to learn more about working with geofences in GeoEvent Server.

When configuring GeoTagger, you must select a spatial operator to specify the relationship that must be satisfied in order for the processor to tag a GeoEvent. For example, you might want to enrich GeoEvents by tagging them with the name of any geofence a GeoEvent's polygon intersects.

GeoTagger supports a range of spatial operators including Contains Any, Crosses Any, Disjoint Any, Enter Any, Equals Any, Exit Any, Inside Any, Intersects Any, Outside Any, Overlaps Any, Touches Any, and Within Any. These operators assume any geofence being considered, which satisfies the operator's defined spatial relationship, is sufficient to trigger GeoTagger to enrich the GeoEvent being processed.

For example, if the Intersects Any spatial operator is selected, and several dozen geofences modeling non-overlapping areas of interest are being considered, then the name of any geofence whose area intersects a GeoEvent's geometry would be added to that GeoEvent being processed.

Note:

It is common to think of a geofence as modeling an area of interest, implying that geofences are always polygon geometries. A geofence could also be a point or polyline geometry, as the list of supported spatial operators implies. A polygon geometry associated with a GeoEvent could be tested to see if it intersects, crosses, or contains a geofence whose geometry is a point or polyline.

When specifying the name of the field containing a GeoEvent's geometry, GeoTagger will accept either the name of the event field or a tag (typically the GEOMETRY tag) that has been applied to a field in the GeoEvent Definition.

GeoTagger alters the GeoEvent'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 participates. Specify a name for the new resulting GeoEvent Definition as well as a name for the field the GeoTagger will write its enriched values.

Three options are available for how the GeoTagger will format its enriched values. Delimited Value specifies that geofence names should be written as a simple comma-separated list. The other two options format the enriched values as a JSON List or as elements in a JSON Group. Configuring GeoTagger to include the name of the geofence category in the enrichment and returning the United States states and counties as separate categories of geofences, GeoTagging enrichment might take the following forms:

• List: ["UnitedStates/California","Counties/San_Bernardino"]
• Group: [{"Category":"UnitedStates","Name":"California"},{"Category":"Counties", "Name":"San_Bernardino"}]

For more information on the GeoTagger Processor, see the Introduction to GeoEvent Server tutorial available from GeoEvent Server tutorials.

Incident Detector

The Incident Detector Processor can be used to indicate that a received GeoEvent satisfies some condition and an incident should be opened. For example, assume a data stream is reporting vehicle positions and their current speed. Incident Detector could generate an incident when any of the vehicles exceed a certain rate of speed or when any enter a particular area of interest or geofence. As new updates are received from the tracked vehicle, the ongoing incident in GeoEvent Server will be updated. The incident will be closed once the vehicle resumes a safe rate of speed or leaves the geofence area.

Incident Detector is different from other processors in that the GeoEvents sent from the processor are not copies (or derivatives) of GeoEvents received by the processor. GeoEvents sent from the processor are associated with the incident GeoEvent Definition that is created when GeoEvent Server is installed.

Incident Detector uses specified attribute and spatial conditions to detect, generate new, and update ongoing incidents. Open incidents remain in an ongoing state until closed. Incidents are closed when a GeoEvent is received that satisfies the closing condition or when no GeoEvents associated with the incident are received within a specified period of time.

When configuring Incident Detector, you must specify an opening condition; a closing condition, however, is optional. If a closing condition is not specified, the processor will use a logical negation of the opening condition as an implicit closing condition.

Note:

For more information on spatial relationship operators and how to construct the attribute and spatial expressions used for opening and closing conditions, see Filters.

Note:

GeoEvents sent into Incident Detector must have a GeoEvent Definition containing a TRACK_ID. The processor uses this tagged field to associate incidents it creates with GeoEvents it receives (which in turn are associated with a discrete object, vehicle, sensor, or other item being monitored).

With Incident Detector, you must specify a name that can be used to identify incidents opened by the processor. For example, an Incident Detector Processor created to detect incidents of speeding vehicles could associate the string Speeding Vehicle with incidents it creates.

The opening and closing conditions specified for Incident Detector can be either attribute based or based on a spatial relationship with a geofence. Like a filter, if the data associated with a received GeoEvent satisfies the specified expression, Incident Detector will detect the condition and either open a new incident, update an ongoing incident, or close an incident.

The processor can be configured to set a severity level associated with incidents. The available severity levels are notification, warning, and urgent. Incidents are limited to a single severity level; the processor must be edited and the GeoEvent Service republished in order to change the severity level.

With Incident Detector, you must specify the type of incidents the processor will create:

• Point-In-Time incidents have no closing condition. They are considered instantaneous and are closed immediately after they are generated and have no incident duration.
• Cumulative incidents have both an opening and a closing condition. The time between the incident's generation and its expiry, or closing, is the incident's duration. Cumulative incidents are monitored and updated by GeoEvent Server as additional event data is received.

Each incident generated by Incident Detector has an associated geometry. The type of geometry is specified when the processor is configured. Incident Detector is typically configured to associate a point geometry with incidents it creates to model an incident as having occurred at a specific location at a specific time. However, multipoint and polyline are also supported geometry types for incidents created by the processor.

The processor will automatically close an ongoing incident if it has not received an update for that incident's TRACK_ID within a specified period of time. Specify an appropriate expiry time (in seconds) when configuring Incident Detector to define this behavior. Incidents will expire and transition to a closed state, even if GeoEvents satisfying the processor's closing condition have not been received, if an update has not been received before the timer counting down the expiry time expires. Specify a value of zero for the expiry time to disable automatic expiry for incidents created by the processor.

For more information on the Incident Detector Processor, see the Introduction to GeoEvent Server tutorial available from GeoEvent Server tutorials.

Intersector

The Intersector Processor can be used to generate a geometry representing the intersection between a geofence and a GeoEvent's geometry. The GeoEvent geometry is considered the base—the geofence is the geometry being evaluated to determine if an intersection exists.

Note:

The intersection between two geometries is generally equal to or less than the geometric dimension of the geometries being considered. For example, if a GeoEvent's associated geometry is a point, even if the specified geofences geometry is a polyline or polygon, the intersection (assuming one exists) must be a point. If a GeoEvent's associated geometry is a polyline and the specified geofences geometry is a polygon, the intersection is most likely a line but could also be a point.

The processor requires two discrete geometries be specified. You will not, for example, be able to use a regular expression to specify several different geofences and obtain the intersection of each geofence with the geometry associated with the GeoEvent being processed.

The processor can be configured to either replace the GeoEvent's geometry with the discovered intersection or write the intersecting geometry into a new field. Adding a new field to a GeoEvent alters the GeoEvent'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 participates.

For more information on the Intersector Processor, see the Introduction to GeoEvent Server tutorial available from GeoEvent Server tutorials.

No Operation

A No Operation Processor takes no action and has no effect on GeoEvents it receives. GeoEvents pass through this processor as if it did not exist. This processor could be used in a GeoEvent Service as a stub or placeholder for an actual processor you want to configure later, allowing you to focus on designing and testing other parts of the GeoEvent Service.

A No Operation Processor can be useful in other scenarios as well, including the following:

• Troubleshooting a published GeoEvent Service that is not working as expected. Configuring a No Operation Processor to perform no operation effectively removes it from the GeoEvent Service without forcing the GeoEvent Service's workflow to be redrawn.
• Designing a processing and filtering workflow in a GeoEvent Service before development on a particular component has been completed. Once development of the components is completed, a No Operation Processor can be reconfigured as another type of processor.
• Demonstrating how to temporarily turn off the processing being performed by particular components of a GeoEvent Service. By configuring an existing processor as a No Operation Processor and republishing the GeoEvent Service, the processing being performed by GeoEvent Server can be highlighted.

Projector

Event data frequently expresses coordinate values in geographic space using latitude and longitude. The Projector Processor can be used to project a GeoEvent's geometry from its native coordinate system to another spatial reference. For example, you might want to explicitly project event data in order to review its coordinate values in the context of a particular coordinate system.

It is recommended you understand the native coordinate system of the streaming data and how it relates to other spatial data you might have imported such as geofences. ArcGIS Server and GeoEvent Server typically project geometries as needed so spatial evaluations are conducted in a common spatial reference. ArcGIS Server will project data it receives to match a feature service's spatial reference, for example, before creating or updating features. GeoEvent Server will project spatial data on-the-fly before evaluating the data for intersection with a geofence.

Use this processor when you want to explicitly project the GeoEvent's before additional filtering or processing steps occur in a GeoEvent Service.

The processor requires that a field containing the geometry be specified. You can specify either the GeoEvent field name or a tag applied to a field within a GeoEvent Definition that identifies the geometry field. The processor also requires the Well Known Identifier (WKID) of the coordinate system to which the input data will be projected. The WKID for the WGS 1984 World Geographic coordinate system, for example, is 4326.

Note:

For more information on supported coordinate systems, see Using spatial references.

The Projector Processor can be configured to replace the GeoEvent's geometry with the projected geometry or place the projected geometry into a new field. Adding a new field to a GeoEvent alters the GeoEvent'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 participates.

For more information on the Projector Processor, see the Introduction to GeoEvent Server tutorial available from GeoEvent Server tutorials.

Simplifier

The Simplifier Processor can be used to correct a GeoEvent's associated geometry to render the geometry topologically consistent with its type. Simplify has no effect on point geometry. Multipoint geometry will snap all vertices to a grid appropriate for the geometry's spatial reference and then remove duplicate vertices. Polyline and polygon geometries with self-intersecting segments will be reconstructed with multiple paths or rings to produce a topologically correct multipart polyline or polygon.

Simplification is not the same as generalization. Simplification does remove unnecessary vertices along an otherwise topologically correct line segment or reshape a geometry to reduce detail to produce a geometry for more efficient display at small map scales. The purpose of simplification is to produce a feature that is valid for insertion into a geodatabase. Features created in an ArcGIS Desktop editing session are already topologically correct and simple. Features polled from a feature service do not require simplification before processing them in a GeoEvent Service.

Simplifier requires the GeoEvent field containing the geometry be specified. You can specify either the GeoEvent field name or a tag applied to a field within a GeoEvent Definition that identifies the geometry field.

The processor can be configured to replace the GeoEvent's geometry with the simplified geometry or place the simplified geometry into a new field. Adding a new field to a GeoEvent alters the GeoEvent'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 participates.

For more information on the Simplifier Processor, see the Introduction to GeoEvent Server tutorial available from GeoEvent Server tutorials.

Symmetric Difference Creator

The Symmetric Difference Creator Processor can be used to clip or remove the intersecting portion of a GeoEvent's geometry and a geofence from the union of the two geometries. The symmetric difference of two geometries is essentially an exclusive OR statement.

Symmetric Difference Creator requires two discrete geometries be specified. You will not, for example, be able to use a regular expression to specify several different geofences and obtain a symmetric difference for the collection of geometries. The processor also requires geometries to have the same type—so you will not, for example, be able compute the symmetric difference between a point and a polyline as a union of the two.

The processor can be configured to replace the GeoEvent's geometry with the computed symmetric difference or place the symmetric difference into a new geometry field. Adding a new field to a GeoEvent alters the GeoEvent'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 participates.

For more information on the Symmetric Difference Creator Processor, see the Introduction to GeoEvent Server tutorial available from GeoEvent Server tutorials.

Track Gap Detector

The Track Gap Detector Processor can be used to detect the absence of events from streaming data. Like Incident Detector, GeoEvents sent from Track Gap Detector are not copies (or derivatives) of GeoEvents received by the processor. GeoEvents sent from the processor are associated with the TrackGap GeoEvent Definition created when GeoEvent Server is installed.

GeoEvents sent to a Track Gap Detector Processor must have a GeoEvent Definition with a TRACK_ID. The processor uses this tagged field to determine when GeoEvents are no longer being received. A processor must receive at least one GeoEvent with a given TRACK_ID before it will be able to detect the absence of GeoEvents for that track.

With the Track Gap Detector Processor, you must specify both the Gap Duration and Gap Detection Interval:

• Gap Duration specifies the number of seconds the processor will wait before determining expected data has not been received.
• Gap Detection Interval specifies the number of seconds in each polling interval.

For example, assuming a Track Gap Detector Processor is configured with a gap detection interval of 120 seconds and a gap duration of 300 seconds, the processor would check its internal register of received GeoEvents every two minutes (120 seconds) to see if any TRACK_ID in its registry had not been observed within the last five minutes (300 seconds).

The gap detection interval also controls how often notifications are generated. When the notification mode is set to Continuous, a new TrackGap event will be generated on each poll of the processor's internal registry for each TRACK_ID expected but not recently received. If you prefer a single notification when a gap is first detected, followed by a second event to notify you when the expected GeoEvents are once again being received, specify the On Change notification mode.

Finally, when configuring a Track Gap Detector Processor you can specify the GeoEvent field that contains the geometry. If a GeoEvent field name is specified, the processor will append the geometry from the most recently received GeoEvent to TrackGap events it generates. For example, if a data stream was reporting the position of vehicles and the processor was configured to poll every 30 seconds to determine if a gap of at least 120 seconds existed since the last received vehicle report, the processor could be configured to include the last reported vehicle location with its gap notification events.

Union Creator

The Union Creator Processor can be used to produce a geometric union of a GeoEvent's associated geometry with one or more geometries you have imported as geofences. The processor requires the GeoEvent field containing the geometry be specified. You can specify either the GeoEvent field name or a tag applied to a field within a GeoEvent Definition that identifies the geometry field.

The processor can be configured to either replace the GeoEvent's geometry with the union of the specified geometries or place the union into a new geometry field. Adding a new field to a GeoEvent alters the GeoEvent's schema, which requires GeoEvent Serverto 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 participates.

Unlike other processors, such as Difference, Symmetric Difference, and Intersector, which only operate with two discrete geometries, the Union Processor accepts a regular expression, allowing several different geofences to be specified. Consequently, you are able to obtain the union of a received GeoEvent's geometry with one or more geometries that have been imported as geofences.

For more information on the Union Creator Processor, see the Introduction to GeoEvent Server tutorial available from GeoEvent Server tutorials.