NOTE: The ArcGIS GeoEvent Processor team updates the product tutorials frequently to reflect the latest version

of the software. Depending on

the product version you are using, there may be inconsistencies between your environment and illustrations or specific steps in the exercises. The
concepts outlined in the exercises, however, should be applicable across product versions.

Introduction to GeoEvent Processor Appendix A

GEP 10.2.x / Rev

Introduction to ArcGIS GeoEvent Processor Appendix A

Appendix A Overview.................................................................................................................................... 3
Working with coordinate values in GeoEvent Processor .............................................................................. 3
Simulating event data with projected coordinate system values............................................................. 4
Using a Field Calculator Processor to compute a Geometry ........................................................................ 6
Designing JSON expressions to simulate events with geometries other than points ................................ 10
Working with different representations of date/time ............................................................................... 15
Adapting date/time values within an input ............................................................................................ 15
Using a Field Calculator to offset a date/time value .............................................................................. 16

Introduction to GeoEvent Processor Appendix A

March 2014

Page 2 of 17

Appendix A Overview
Material in this appendix is intended to go beyond the introductory exercises presented in the various
modules of this tutorial and provide a deeper dive into specific topics highlighted by questions sent to
the product development team from users.
It is occasionally necessary to limit an exercises narrative in order to focus on a particular concept for
users unfamiliar with the product. One example is the different ways coordinate values can be specified
in a simulation file. Coordinate values in the simulation files used in the exercises are generally specified
in decimal degrees for a Geographic Coordinate System (GCS), for example, when GeoEvent Processor
and the GeoEvent Simulator are perfectly capable of handling coordinate values expressed in linear
units for a Projected Coordinate System (PCS).
There are also certain tips or tricks analysts can use to work with data modeled within a GeoEvent. For
example, date/time values can be offset by subtracting a numeric value from (or adding a numeric value
to) the date using a Field Calculator processor. A Field Calculator can also be used to generate a JSON
string which a Field Mapper can interpret as a Geometry. Details such as these, if included in an exercise
narrative, tend to distract students seeking to learn the basics of the product. These nuggets are then
hard to locate later once an analyst has had a chance to work with the GeoEvent Processor.
If you discover an innovative design for a GeoEvent Service, or uncover a configuration for an Input,
Output, Processor, or Filter which solves a particular problem, please share your success on our ArcGIS
GeoEvent Processor Forum: http://forums.arcgis.com/forums/257-GeoEvent-Processor

Working with coordinate values in GeoEvent Processor

Nearly all of the exercises in the introductory tutorial rely on comma separated text loaded into a
GeoEvent Simulator. Some of the simulation files express event locations as a quoted pair of values
as illustrated below. Of course this is not the only way event data might express a location. In fact
specifying coordinates this way is really a shortcut which makes some implicit assumptions.

In the illustration above, the events location is a single value presented as a string. The coordinates in
the string are assumed to be in decimal degrees, implying a Geographic Coordinate System (GCS), with
the longitude preceding the latitude. Specifying the values as a quoted string allows the text adapter used
by the Input to apply special handling in order to interpret the value as a location. If you look closely at
the GeoEvent Definition in exercises which use this shortcut, you will see that the quoted pair of values is
handled as a Geometry. The Input is actually doing quite a bit of work to convert the pair of coordinates
from a simple string into the expected Geometry data type.

Introduction to GeoEvent Processor Appendix A

March 2014

Page 3 of 17

Simulating event data with projected coordinate system values

If an analyst wanted to design simulation data whose coordinate values were not in decimal degrees,
but were instead linear measures for a Projected Coordinate System (PCS), the shortcut illustrated
above couldnt be used because the adapter cannot assume to know in which projection the values are
expressed. Clearly the coordinates 950202,443472 are different than -105.077138,40.581495 even
though both specify the same location in Fort Collins, Colorado in the United States.
You might recall that the schema of FlightData.csv, the simulation file used in Module 1 and illustrated on
the previous page, is different than that of FeatureFlights.csv used in Module 2 (illustrated below).

Notice that the coordinate values for the latter simulation file, while still in decimal degrees for a GCS,
are expressed as separate data values. The Build Geometry From Fields option is explicitly selected in the
exercise in Module 2 so that the Input will retrieve the coordinate values individually and use them to
construct a Geometry.

Notice in the illustration above that the parameters below X Geometry Field and Y Geometry Field have
been left empty. The exercise is allowing the Input to continue to assume a Geographic Coordinate
System specifically the WGS84 coordinate system whose WKID (Well-Known Identifier) is 4326.
When event data expresses coordinate values in linear units such as meters or feet (rather than decimal
degrees), the most reliable and flexible approach is to have each event include the numeric WKID of the
projected coordinate system associated with the events coordinate values. When each event specifies

Introduction to GeoEvent Processor Appendix A

March 2014

Page 4 of 17

both its coordinate values and a projection identifier for those coordinates events can potentially express
locations in a variety of different projections.
The illustration below shows how an Input using the Text adapter (the adapter coupled with the Receive
text from a TCP Socket used in the exercise in Module 2) would be configured to support coordinates in
linear units for a Projected Coordinate System. Notice that the coordinates are obtained from the events
fields, as they are in the illustration on the previous page. However, the GeoEvent Definition created for
these events, SiteData-TcpTextIn (see illustration next page), specifies event fields XCoord, YCoord, and
WKID rather than just Longitude and Latitude.

Event data, with coordinates for the StatePlane Colorado North (US Feet) coordinate system, might look
something like the following where 103012 is the WKID for the projected coordinate system:

The SiteData-TcpTextIn event definition illustrated below supports the comma separated simulation data
illustrated on the previous page. Notice that the event definition contains an extra field named Location.
The Input will place the Geometry it builds using the events XCoord, YCoord, and WKID into this field.

Introduction to GeoEvent Processor Appendix A

March 2014

Page 5 of 17

The next section will take a look at how a Field Calculator can be used to build a Geometry using data
obtained from an events fields rather than relying on an Input component to do this.

Using a Field Calculator Processor to compute a Geometry

The discussion so far has assumed that the event data to be processed includes a WKID, which will not
always be the case, and since an analyst probably has little if any influence over the data provider, we
need a way to build a Geometry using data retrieved from an events fields within the GeoEvent Service,
after the data has been received by the Input and passed along to the next service element.
For example, consider the event data illustrated on the next page. The data is expressed as a JSON
structure with information common to all survey sites specified in a header and the unique data for each
site expressed within a list element Sites.
The Geometry for this example is Point Geometry we will explore further how to simulate Geometries
other than Points later in this appendix. When working with Point Geometry, there is a relatively simple
solution to our problem that each site event record does not contain the needed WKID. We will use the
Field Calculator processors ability to incorporate the coordinate values from each site into a String
which can later be interpreted as a Geometry.
A new Receive JSON on a REST endpoint Input was created with its Create GeoEvent Definition property
initially set so that an event definition matching the expected data structure would be generated based
on the first event received.
You may find it is a good practice to allow an Input to initially generate an event definition for you based
data discovery, then fine tune the generated GeoEvent Definition and reconfigure the Input to use the
refined event definition.

Introduction to GeoEvent Processor Appendix A

March 2014

Page 6 of 17

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50

{
"SiteID": "9c272a7d-3698-4cb0-95db-c4dbecd4ddae",
"Description": "Northern Colorado - Fort Collins area",
"Projection": "NAD 1983 (2011) SPCS Colorado North - FIPS 0501 (US Feet)",
"WKID": 103012,
"Sites": [
{
"SiteName": "Alpha",
"LastUpdated": "5/27/2012 13:26:33 PM",
"YCoord": 1453029.6,
"XCoord": 3122232.5
},
{
"SiteName": "Bravo",
"LastUpdated": "5/27/2012 13:26:39 PM",
"YCoord": 1448394.2,
"XCoord": 3124125
},
{
"SiteName": "Charlie",
"LastUpdated": "5/27/2012 13:26:45 PM",
"YCoord": 1450295.2,
"XCoord": 3131863.7
},
{
"SiteName": "Delta",
"LastUpdated": "5/27/2012 13:26:51 PM",
"YCoord": 1442298.3,
"XCoord": 3126221.3
},
{
"SiteName": "Echo",
"LastUpdated": "5/27/2012 13:26:59 PM",
"YCoord": 1435510.1,
"XCoord": 3119598.1
},
{
"SiteName": "Foxtrot",
"LastUpdated": "5/27/2012 13:27:03 PM",
"YCoord": 1428817.4,
"XCoord": 3125118.9
},
{
"SiteName": "Golf",
"LastUpdated": "5/27/2012 13:27:13 PM",
"YCoord": 1418374.7,
"XCoord": 3133426.2
}
]
}

Introduction to GeoEvent Processor Appendix A

March 2014

Page 7 of 17

For this example lets assume that the number of site elements in the Sites list is variable or unknown, so
we would prefer to receive each site as a separate GeoEvent.
An Input suitable for receiving JSON via a REST endpoint can be used to generate an event definition with
the Sites element treated as the root element of the JSON structure. Information from the header will not
be available as the event definition only provides access to fields in site record.

Notice that the name of the GeoEvent Definition in the illustration above includes a descriptive keyword
AutoGenerated. Once event data has been received and you have had a chance to review the generated
event definition, it is recommended that the Input be reconfigured to specify an event definition to use
rather the continuing to allow the Input to create one based on data discovery.
In the illustration below, the generated event definition has been copied and renamed. Notice that the
analyst, not the Generic-JSON inbound adapter, is identified as the GeoEvent Definition owner. The event
definition SiteData-JSON-AutoGenerated was deleted.

Having reconfigured the Input to use the SiteData-JSON event definition illustrated on the previous page,
we can now design a GeoEvent Service incorporating the Input and a Field Calculator which will build a
JSON string using the XCoord and YCoord values from each event. The JSON string will be compatible with
the Esri Feature schema for a Point Geometry.

Introduction to GeoEvent Processor Appendix A

March 2014

Page 8 of 17

The JSON string is built by entering the necessary literal strings and field names into the Field Calculator
processors Expression parameter. Consider the following illustration, which breaks the expression into
multiple lines to better show the literal string values within the pairs of single-quotes:

The expression would need to be entered on a single line when configuring the Field Calculator.

The Field Calculator builds a String representation of an Esri Feature compliant Point Geometry. The
string value must be converted to an actual Geometry data type before it can be used as a Geometry.
This can be accomplished with a Field Mapper processor.
Remember, when updating or adding features to a published Feature Service, it is recommended that
you import a GeoEvent Definition from the target feature layer and incorporate a Field Mapper
processor if necessary to ensure that event data being output from a GeoEvent Service matches the
targeted feature layers schema.

Introduction to GeoEvent Processor Appendix A

March 2014

Page 9 of 17

Designing JSON expressions to simulate events with geometries other

than points
The previous section illustrated how a Field Calculator can be used to build a string representation of
a Point Geometry. Nearly all of the exercises in the introductory tutorial use Point Geometry for their
simulated event data. The GeoEvent Simulator will accept simulation files containing JSON strings, if
you want to simulate polyline or polygon data.
Keep in mind that strings you design should be expressed as a single line of text and should be quoted
to ensure that the entire line is treated as a single attribute value of the event being simulated. Also,
literal quotes in the JSON will need to be escaped with double-quotes. An example using expressions of
polyline strings is included in the exercise illustrating spatial enrichment of GeoEvents in Module 4. The
narrative and illustration which follow are intended to further explore this capability.
The JSON representation of an Esri Feature compliant polyline or polygon can be quite long. The example
in the previous section illustrating the construction of a string representation of a Point was reasonably
accomplished within a Field Calculator, but you may find configuring a Field Calculator to build a JSON
string for a polyline or polygon challenging.

Introduction to GeoEvent Processor Appendix A

March 2014

Page 10 of 17

The illustration below shows the JSON returned when a polyline feature layer is queried from a published
feature service. In the illustration, a single polyline feature has been expanded to show both its attribute
values and the five vertices making up its geometry.

When creating a JSON text representation of a polyline for a GeoEvent simulation file, we only want the
geometry portion of the JSON block. Also, the keyword geometry will be assumed, so we only want to
take the paths element with its enclosing curl-braces.
Consider the illustration on the next page. The paths element has been highlighted in yellow and the
needed curl-braces are indicted with red arrows.

Introduction to GeoEvent Processor Appendix A

March 2014

Page 11 of 17

Reducing the JSON indicated in the illustration above to a single line of text, and adding the necessary
quotation characters, we obtain the JSON string we need for the comma separated event simulation file.
The numeric precision has been reduced to better communicate the structure of the string.
"{ ""paths"": [ [ [ -117.2619, 32.2951 ], [ -117.2586, 32.2970 ], [ 117.2568, 32.3006 ], [ -117.2541, 32.3032 ], [ -117.2508, 32.3080 ] ] ] }"

The illustration below shows the JSON incorporated into a simulation file.

The illustrations below show other configurable elements, such as the GeoEvent Definitions and
GeoEvent Service, used to validate that the simulation data illustrated on the previous page can
be used to add features to feature layer within a published feature service.

Introduction to GeoEvent Processor Appendix A

March 2014

Page 12 of 17

The illustrations below summarize how to design a simulation file whose events have associated
polygons rather than polylines.
First, either identify or develop a JSON structure with a rings element:

Introduction to GeoEvent Processor Appendix A

March 2014

Page 13 of 17

Next, reduce the JSON to a single line of text, adding the necessary quotation characters. The numeric
precision below has again been reduced to better communicate the structure of the string.
"{ ""rings"": [ [
117.2568, 32.3006
117.2469, 32.3059
117.2577, 32.2941

[ -117.2619, 32.2951 ],
], [ -117.2541, 32.3032
], [ -117.2494, 32.3032
], [ -117.2619, 32.2951

[ -117.2586, 32.2970 ], [ ], [ -117.2508, 32.3080 ], [ ], [ -117.2528, 32.2987 ], [ ] ] ] }"

Finally, incorporate the JSON describing the polygon into a comma separated simulation file.

Introduction to GeoEvent Processor Appendix A

March 2014

Page 14 of 17

Working with different representations of date/time

You have probably noticed, when querying features through a feature layers REST endpoint, that the
REST API encodes date/time values as a UTC value expressed in milliseconds.
The fields in a feature service each have a specified
type such as esriFieldTypeString, esriFieldTypeInteger,
or esriFieldTypeDate.
The REST API is reporting a value which represents the
number of milliseconds since the Unix Epoch, midnight
on January 1, 1970.
Within GeoEvent Processor, event data in a GeoEvent
is associated with an underlying Java class types such
as String, Integer, Long, and Date.
This section will focus on GeoEvent Processor flexibility
when working with date/time values.

Adapting date/time values within an input

The GeoEvent Processor was designed to support the ISO 8601 Date and Time format which specifies
that a complete date as a string YYYY-MM-DDThh:mm:ssTZD which includes hours, minutes, seconds,
with a literal T separating the date and time portions of the string and a time zone designation.
The formal ISO 8601 format is not the only acceptable format however. As you have already seen in
various exercises, a simulation file can express a timestamp as 3/16/2012 02:25:37 PM the Input
recognizes the value as a date/time and handles the conversion to a Date type value. An adapter used
by the Input has been developed to automatically handle common ways of expressing date/time values.
When an Input such as Receive text from a TCP Socket is used to receive comma separated text, an
adapter configured within the Input is responsible for retrieving the event data and constructing a
GeoEvent. The Text adapter includes an ability to construct a Date value given a string representation
of an events timestamp. This same ability is included in Inputs which use the JSON adapter to receive
event data modeled as JSON structures.
Notice the parameter Expected Date Format in the illustration below. This is an Advanced property
available with several different Inputs. The parameter allows an analyst to specify a mask which the
adapter can apply to a field containing a representation of a date/time in order to interpret the value
as a Date.

Introduction to GeoEvent Processor Appendix A

March 2014

Page 15 of 17

Hovering over the help icon to the left of the

parameters text field will display help on how to
build a date/time mask for interpreting custom
expressions.
For example, if incoming event data were expressing
its date/time values as a shortened string with dashes
in the date (instead of forward slashes) and seconds
were not included with the time, an analyst could use
a mask like the one shown below to enable the Input
to correctly interpret the received string as a Date:

dd-MM-yyyy HH:mm

Using a Field Calculator to offset a date/time value

As illustrated earlier, when using the REST API to query a feature layer for features, date/time values are
returned as long integers. This can be useful if an analyst needs to offset a value using a Field Calculator,
for example, to derive a date/time value for display in a particular client application.
In Java, the underlying primitive data type for a Date value is a Long Integer. Suppose a data provider
has stipulated that the date/time values in events being sent will be in GMT (Greenwich Mean Time),
but an analyst wants to display the values offset as if they were reported for a local time zone.
Using a Field Calculator, the analyst can subtract a known number of hours from the date/time in each
received event in order to derive a local-time equivalent of the events reported time. The value to be
subtracted will need to be a long integer expressed in milliseconds so if the desired offset was 8 hours
to compute a Pacific Standard Time equivalent for the received Greenwich Mean Time, the analyst would
subtract (8hrs x 60min x 60sec) x 1000 or 28,800,000 from the date/time value in each GeoEvent.

Introduction to GeoEvent Processor Appendix A

March 2014

Page 16 of 17

Introduction to GeoEvent Processor Appendix A

March 2014

Page 17 of 17