field enrichment of multiple attributes based on a spatial query?

BenNadler

what is the recommended service configuration for populating existing fields in a geoEvent based on location?

From the ootb processors I see geofencing + GeoTag+Table Join  as the only method. Kinda clunky

Scenario:

     I have 2 spatially dependant attributes that exist in the schema but are blank in the incoming geoevent  (District,DistrictSupervisor) and want

     I would have to first load districts as geofences (possibly many thousands)

     Then I have to GeoTag to get the geofence name, then do a separate Join to get the DistrictSupervisor.

    

     Ideally I am looking for a processor that queries a FS layer or shapefile by the location of the geoEvent and populate one or more attributes  in the same manner as the join.

Is this something we have sitting around somewhere?

Why is this not a standard processor?

RJSunderman

Hello Ben -

My apologies that your question went so long without an answer or reply.

To the best of my knowledge, GeoEvent does not do anything with Shapefiles, and there is no out-of-the-box processor which will query a map service / feature service based on spatial criteria. The Field Enricher processor is the closest match, and as you know, it only accepts a field on which an attribute join can be performed. Therefore the only workflow available, out-of-the-box, for enriching an event with attribute information from a database table based on spatial coincidence with a Geometry is the one you've used:  Load GeoFences, use a GeoTagger processor to determine spatial coincidence (and enrich with the name of a GeoFence), then use a Field Enricher processor to complete the enrichment by performing an attribute join and loading attribute values associated with the GeoFence into the event being processed.

The product team has an issue open in the product backlog ("Allow imported GeoFences to contain both attributes and geometry - Issue #564"). Implementation on this has been deferred because GeoFences, by design, are intentionally light-weight. They are maintained in memory for fast geometric comparisons. There are significant consequences to loading all of the attributes associated with a Geometry into GeoEvent as GeoFence attributes.

I will ask around to see if there is any other advice to offer you, but I think in this case the workflow is by design. A custom processor which provides an event's Geometry to a feature service in order to perform a spatial join is not something I think is being considered.

Esri Technical Support can help you open a case to request product enhancements. If we can get several customers behind a case it will help prioritize the enhancement within the product backlog.

Hope this information is helpful -

RJ