Filters

Filters are configurable components of a GeoEvent Service that filter GeoEvents that do not satisfy specified criteria as they flow from Input Connectors to Output Connectors. ArcGIS GeoEvent Processor for Server filters include attribute filters, spatial filters, and GeoEvent Definition filters.

Attribute filters

Attribute filters in a GeoEvent Service filter events based on attribute criteria. When a filter is added to a service, a service designer will configure the filter element with one or more attribute expressions. The logical combination of these expressions represents the criteria an event must satisfy to pass through the filter.

Some examples of attribute expressions include the following:

altitude >= 2400	Filters all events below a specified threshold value
Title MATCHES .*California.*	Uses a regular expression to look for a substring in a field
CodedStringValue IN Red,Green,Blue	Uses a set of strings to filter for specified coded values
NOT(GEOMETRY ISNULL)	Filters events whose specified field is null

Examples of attribute expressions

The following attribute operators are available:

• Equal (=)
• Not Equal (!=)
• Greater Than (>)
• Greater Or Equal (>=)
• Less Than (<)
• Less Or Equal (<=)
• IN
• ISNULL
• EXISTS
• MATCHES

注:

Checking for NULL strings is not supported. GeoEvent Processor defines a string as empty (a zero-length string) rather than as a null object.

Spatial filters

Spatial filters can be used in GeoEvent Processor to filter events based on spatial criteria. Spatial filters rely on GeoFences, which must be imported into GeoEvent Processor from a feature service prior to configuring a spatial filter. A spatial filter specifies a condition such as inside or outside. GeoEvents that do not satisfy the spatial condition are discarded by the filter. Four essential spatial operators are available for use when configuring spatial filters: inside, outside, enter, and exit.

• Inside—Only allows events whose location is entirely within the specified GeoFence to pass through the spatial filter.
• Outside—Only allows events whose location is entirely outside of the specified GeoFence to pass through the spatial filter.
• Enter—Only allows events whose location represents an entry into the specified GeoFence to pass through the spatial filter. The definition of this condition is when an event exists inside a GeoFence when the previous event from the same track was outside. After an entry condition is detected and the event is allowed to pass through the filter, the tracked object must report at least one event outside the GeoFence before GeoEvent Processor will recognize another entry.
• Exit—Only allows events whose location represents an exit from the specified GeoFence to pass through the spatial filter. The definition of this condition is when an event exists outside a GeoFence when the previous event from the same track was inside. After an exit condition is detected and the event is allowed to pass through the filter, the tracked object must report at least one event inside the GeoFence before GeoEvent Processor will recognize another exit.

See Managing GeoFences to learn more about working with GeoFences.

GeoEvent Definition filters

Every GeoEvent within the GeoEvent Processor has an associated schema that identifies the attribute fields and data types (date, string, integer, and so forth) for the event’s data. This schema is referred to as a GeoEvent Definition. A GeoEvent Definition filter can be configured to filter events based on their event definition.

In general, an event stream can be made up of many different kinds of events. Certain input connectors, such as those that receive JSON and RSS feeds, are capable of generating event definitions based on data they discover in the events they receive. If a service designer needs to ensure that all of the events being processed adhere to a specific schema, a GeoEvent Definition filter could be used to discard events that were not associated with a specific event definition.

Configuring filters using tags

A tag is a label placed on a particular field of a GeoEvent Definition. Tags are similar to field aliases; they support consistency in expressions when different event definitions associate similar data with different field names. Certain built-in tags also identify for GeoEvent Processor fields that contain critical information such as a TRACK_ID or GEOMETRY.

Once a tag has been created and applied to a particular field of a GeoEvent Definition, filters can reference a field by its tag rather than by the field’s name. This is particularly useful when configuring an attribute filter because it allows a single attribute filter to apply the exact same attribute-based criteria to multiple types of events.

See Managing tags to learn more about using tags is GeoEvent Processor.

Configuring filters using regular expressions

The MATCHES operator—available when configuring an attribute filter—supports the use of regular expressions to find a pattern within a target field. Regular expression pattern matching can be a powerful tool for data validation. The full scope and syntax of regular expressions cannot be covered within this help topic, but the examples below help illustrate their use within event filters.

注:

Regular expressions can only be applied to attribute fields of type string.

注:

The specified pattern is matched against the entire string. You cannot enter California to match strings that contain that substring. Specifying a pattern .*California.* accounts for zero or more characters both before and after the substring the filter is supposed to find.

Field value	RegEx pattern	Result
SWA2382	^SWA[0-9]+$	The carat sign (^) anchors the pattern to the beginning of the string; a dollar sign ($) anchors the pattern to the end of the string. The [0-9]+ portion of the pattern specifies that one or more digits 0 through 9 should be found at the end of the string. Any values in the target field that do not begin with SWA, followed by some number of digits representing a flight number, will be discarded by the filter.
02/15/1973	[0-1][0-9][/][0-3][0-9][/][0-1][0-9][0-9][0-9]	The use of numeric ranges such as 0 through 1, 0 through 3, and 0 through 9 specifies the expected values for a mm/dd/yy date string. Values that do not have a two-digit month followed by a two-digit day and a four-digit year, separated by a slash (/), will be discarded by the filter.
3.14159	^[-+]?[0-9]*\.?[0-9]+$	This pattern verifies that the string in the target field can be interpreted as a numeric value. An asterisk (*) in the RegEx pattern matches zero or more instances of the preceding character; a quotation mark (?) matches zero or one instances. The backslash means that the '.' is a literal decimal point, not an any-character wildcard (for example, *). The pattern makes a plus (+) or minus (-) sign the integer portion of a floating point value, and the literal decimal optional (may occur zero times).

Regular expression examples