GEOMETRY tag

[MarkBramer]

Hi,

Sounds a little silly, but what exactly does assigning the GEOMETRY tag to a field do?

Here's why I ask:

I have two GE definitions defined as such:

MSG1:

Name	Type	Cardinality	Tags
TrackID	String	1	TRACK_ID
Geometry	Geometry	1	GEOMETRY
DATETIME	Date	1	TIME_START
LAT	String	1	Y
LON	String	1	X
ALT	String	1

MSG2:

Name	Type	Cardinality	Tags
TrackID	String	1	TRACK_ID
DATE	String	1
TIME	String	1
LAT	String	1	Y
LON	String	1	X
ALT	String	1
PITCH	String	1
ROLL	String	1
YAW	String	1
DateTime	Date	1	TIME_END,TIME_START
GEOM		1

Note that MSG1 has the GEOMETRY tag assigned to the Geometry field but MSG2 does not have the GEOMETRY tag assigned to the GEOM field.

I receive messages of both of these types on one TCP/Text input. I send all messages to one file via a .csv file output. In this log file, all MSG1 messages appear to be messages as they came in on the wire, with the geometry as "x,y,z", which is how I know the feed comes in. All MSG2 messages had the geometries converted to JSON, i.e. "{""x"":99.99, ""y"":99.99, ""z"":0.0, ""spatialReference"":{""wkid"":4326}}"

Why?

When I assigned the GEOMETRY tag to MSG2's GEOM field, all MSG2 messages then had the geometry values as "x,y,z"

Why?

The documentation makes it sound like tags are just used for making your life easier by referring to a tag and not individual names for fields that serve the same function, by may differ in name between GE definitions. But obviously, something more is going on here.

I discovered this through investigating why feature service outputs (Add a feature) were failing for MSG2 when I didn't have the GEOMETRY tag assigned to GEOM (JSON geometries). When I added the GEOMETRY tag, my add feature output worked.  This itself isn't surprising, as I'm guessing the GEOMETRY tag helps with GEP talking to ArcGIS Server for feature additions via feature services.  But why the conversion to JSON if I do not have the GEOMETRY tag assigned?

What is going on behind the scenes for the GEOMETRY tag? What is it used for? Are there any other functionality tidbits for the GEOMETRY tag? How about any of the other out-of-box tags like TRACK_ID, TIME_END, and TIME_START?

Thanks!

[RyanElliott]

Your understanding is correct.  In general, the GEOMETRY tag is used as an alias for the field containing the working geometry of the GeoEvent.  This helps when you have several types of GeoEvents coming into a processor, and the processor doesn't know what the name of the geometry field is going to be. 

The other reason that it is necessary to use a GEOMETRY tag is to deal with situations where there are multiple geometry fields in a single GeoEvent.  Processors need to know which geometry to use when doing spatial operations.

The issue you mentioned where the field value is being written differently sounds like it is a problem with the Text Adapter.  It seems to be formatting the data differently depending on if it is tagged or not.  That shouldn't be happening without user intervention.

TRACK_ID is even more critical because there are several processors and outputs that need to know how to group GeoEvents so that they know which GeoEvents to group together into the history of a single entity. 

TIME_START is used to know which time value to use when doing temporal calculations.  There can be (and often are) multiple timestamps on a single GeoEvent.  It is used by several built-in processors and output connectors.

TIME_END represents that the GeoEvent is expected to stop being fresh.  After this point the GeoEvent is said to be "stale" information and should be considered "historical", not "current".  This is not used in any of the processors packaged with the 10.2 release of GeoEvent Processor, but is expected to be used in the near future.

[MarkBramer]

Thanks - good info.  Are you saying the JSON formatting issue is a bug?

[RyanElliott]

Well, I may have worded that a little too strongly calling it a bug.  When there is a geometry-tagged field that is a Point (not line/polygon), the Text adapter considers this to be a simple basic use case, and writes out the x/y/z values as simple delimited values.  Otherwise the Adapter falls back on the default behavior of converting the geometry to a JSON object, which is more technically accurate but a little harder to read if you're not a GIS expert.