Hello Nathan,
I have confirmed with our developer who maintains the various processor implementations that what you are trying to do with the Union processor will not work. Currently the ${field_name} construct is only supported as part of a filter expression, or when using the GeoTagger processor.
What we need, but do not have, is a Field Enricher capable of matching multiple feature records given a single primary key (e.g. a one-to-many enrichment). This is an enhancement request that has been in the product backlog for quite a while. There is a separate enhancement request to refactor all of the Geometry Overlay processors (e.g. Buffer, Convex Hull, Symmetric Difference, Union ... etc.) to allow dynamic substitution of event attribute field values.
Thinking through the problem, I could imagine configuring a GeoTagger processor to logically "OR" two mutually exclusive conditions such as:
- INTERSECTS ${order_id}/.*
- DISJOINT ${order_id}/.*
... that's a start; now I have a comma separated list of the names of all geofences matching the received event record's order identifier.
I could then use a Field Splitter processor (a custom processor available from our Gallery) to split the comma separated list of geofence names to obtain a series of individual event records. Each event record would have the received ${order_id} and the name of exactly one geofence associated with the ${order_id} of interest. Assuming that the ${meter_id} used as each geofence's name was unique I could then use a Field Enricher to enrich each event record in the series with the geometry of the feature record used to import the named geofence in the first place.
That approach requires quite a lot of processing, though, and probably won't scale if you have a high volume of geofences or if the velocity at which you are receiving event records is more than just a few event records per second. And it still doesn't give you what you were looking for originally -- a single geometry representing a UNION of each point geometry associated with the ${order_id} attribute value originally received.
Might it be an option for you to represent the locations of each ${meter_id} as a multi-point geometry rather than several individual point geometries? If each ${meter_id} were a vertex of a multi-point geometry then the geometry you get back when enriching an event record using ${order_id} to look-up a single multi-point feature would have the coordinates for each ${meter_id}.
Without changing your data model, I don't think you'll be able to do what you want using the current release of GeoEvent Server, unless you develop a custom processor using the GeoEvent Server Java SDK. I would probably recommend looking at developing a custom Python script or Desktop GP Tool rather than trying to force GeoEvent Server to do what you want to do. Unfortunately the only two simple approaches I can think of, using GeoEvent Server, both have open / pending enhancement requests.
- RJ
