A GeoEvent Definition defines the schema of an event record. Event records routed between filters and processors in a GeoEvent Service have attributes with specific data types, such as dates, strings, integers, or geometries. The attribute field names and their data types are specified in a GeoEvent Definition. To view GeoEvent Definitions, click Site > GeoEvent > GeoEvent Definitions in ArcGIS GeoEvent Manager.
Introduction to GeoEvent Definitions
When configuring an input connector, you must specify a GeoEvent Definition that the input can use to adapt raw data ingested from a sensor. The input adapts data formatted as JSON, XML, or delimited text to create an event record. In the same way, an output connector uses a GeoEvent Definition to extract data from a processed event record and format it for dissemination.
GeoEvent Definitions can be created and edited by users. Some input connectors can create event definitions based on data they discover in the received data. Administrators import event definitions to support operations such as updating feature records in a published feature service.
Note:
Two GeoEvent Definitions, incident and TrackGap, are installed with GeoEvent Server. These GeoEvent Definitions can only be viewed or copied; they cannot be deleted or edited. The incident detector processor and track gap detector processor use these GeoEvent Definitions.
The introduction to GeoEvent Server tutorial contains exercises illustrating how to create a GeoEvent Definition, how an input connector builds a GeoEvent Definition from data it receives, and how to import a GeoEvent Definition from a published feature service. You can access the tutorial from GeoEvent Server tutorials.
GeoEvent Definition field data types
Each field contained in a GeoEvent Definition has an associated field data type. This field data type is used when input connectors construct an event record from streaming event data or when event records are deconstructed before sending an event record through an output connector.
The available field data types are as follows:
- Boolean
- Date
- Double
- Float
- Geometry
- Group
- Integer
- Long
- Short
- String
The geodatabase supports data types other than those supported by GeoEvent Server. The following table shows how common GeoEvent Server data types map to geodatabase field data types:
| GeoEvent Server data type | Geodatabase field data type |
|---|---|
Double | esriFieldTypeDouble |
Float | esriFieldTypeSingle |
Date | esriFieldTypeDate |
Short | esriFieldTypeSmallInteger |
Integer | esriFieldTypeInteger |
Long | esriFieldTypeDouble |
String | esriFieldTypeString |
Geometry | esriFieldTypeGeometry |
Note:
GeoEvent Server supports Java native data types, such as string, date, Boolean, and more. The geodatabase uses esriFieldType constants to define field data types. Not all Java native data types used by GeoEvent Server map directly to geodatabase field data types. For example, while GeoEvent Server supports the Boolean data type, the geodatabase does not have an esriFieldTypeBoolean data type. As a result, when publishing a hosted feature layer, Boolean values (true or false) are handled using the esriFieldTypeString data type and stored as string literals (“true” or “false”) when written to a geodatabase. If your real-time data includes true or false values supported by both the JSON data object specification and the Java native data type, it is recommended that you explicitly convert them to string literals “true” or “false” in your GeoEvent Service before writing them to a geodatabase.
Field cardinality
Some event-based data streams define schemas in which a single field has multiple entries, such as an array. These fields are represented in GeoEvent Definitions as fields with a cardinality greater than one. Field cardinality is an advanced feature meant to support data streams in which this condition is found. Administrators can configure cardinality of a GeoEvent Definition in GeoEvent Manager by changing the cardinality of a field from One to Many.
Field groups
Some data feeds define schemas in which a single field is not a discrete data type (for example, date, string, and integer) but is instead a group containing multiple types of data values. These fields are represented in GeoEvent Definitions as groups. The discrete data types of each field in a group are listed under the field group name.
Support for field groups is another advanced feature meant to support data feeds in which this condition is found. A group field data type can contain nested groups, enabling complex structures to be created.
Configure a GeoEvent Definition field to be a group field in GeoEvent Manager by changing the type of field to Group.
Note:
Not all output connectors support event data whose fields contain multicardinal or group structures. For example, when using either the Add a Feature output connector or the Update a Feature output connector, you must use a Field Mapper Processor to flatten an event data structure to match the schema expected by a feature service layer. Another example is when using the Send Features to a Stream Service output connector, the event data structure should be flattened so feature pop-ups generated from a stream layer display simple text values rather than hierarchical JSON.
Field name restrictions
The attribute field names in a GeoEvent Definition cannot contain any of the following characters: $ . [ ] ? * < > ! = { } % ( ). Field names, although not restricted, should also not use meta characters typically recognized as arithmetic or logical operators such as plus (+), minus (-), multiply (*), divide (/), logical AND (&&), or logical OR (||), as well as spaces.
It is recommended that you remove any characters that are not alphanumeric or an underscore from your field names. For more information, refer to Field naming guidelines and the Esri Technical Support article What characters should not be used in ArcGIS for field names and table names.
If the attribute field name of a GeoEvent Definition contains metacharacters that are not recommended, use a Field Mapper Processor to remap the schema of an event record as early as possible in your event processing workflow to address the field naming restrictions.