Filter problem

[VítorCarvalho]

Hi,

I'm developing one service where i use one GeoTagger processor to get the geofenceids.
I have one id and I'm trying to use one filter to identify if my id is in the geofenceids.
I configured the filter as "myId IN ${geofenceids}" and it never work.
I made one test with absolute values as ""myId IN 1,16,32" and it works well.

What can I do to solve this problem?

Thanks,
Vítor Carvalho

[RJSunderman]

Hello Vitor -

Sorry, but what you are trying to do is not supported by a filter at any of the 10.2.x product releases. The filter will not expand a field name such as ${ValuesList} to build a list of comma separated values.

When configuring a filter with an expression and selecting the IN operator, the Value portion of the expression must be a comma separated list of values. These can be integer values ... 1,16,32 as you discovered. They can also be unquoted strings ... for example abc,def,ghi.

You might refer to the thread Spatial" rel="nofollow" target="_blank">http://forums.arcgis.com/threads/102155-Spatial-filter-Diffe... filter - Different Geofences depending on a field which describes a way to use a filter to compare a geotagged value against another field's value using = and != operators rather than the IN operator.

Hope this information helps -
RJ

[VítorCarvalho]

Hi RJ,
Thanks for your explanation.
If I understood... when I use one GeoTagger processor where I have several overlapping GeoFences, I receive the ids of all of the GeoFences that intersect my position�?� the problem is the same�?� I have one field with something like �??23,24,25�?� and I can�??t find one id (e.g. 24) in this list.

Regards,
Vitor Carvalho

[RJSunderman]

Hello Vitor -

You are correct. When GeoFences overlap and an event is INSIDE the overlapping area the GeoTagger processor's default GeoTag Format, DelimitedValue, will output a comma separated list of GeoFence names.

Because the IN and MATCHES operators within expressions do not support variable substitution, filter expressions such as SearchKey IN ${TaggedValuesList} or TaggedValuesList MATCHES .*${SearchKey}.* which include the name of a field on the right hand side of the expression will not work. The parsing of the second expression in fact - the one using MATCHES with .* regular expression atoms on either end - ends up allowing all of the events through the filter when the parser encounters the unsupported ${SearchKey} in the expression; the filter's implementation is handling the unsupported expression by replacing the entire expression with .* (which matches everything).

If you must handle the case in which GeoFences overlap, I would suggest that you review the forum thread Overlapping" rel="nofollow" target="_blank">http://forums.arcgis.com/threads/105319-Overlapping-geof... geofences with different attributes which presents an alternative to using the default GeoTag Format, DelimitedValue. You might find working with the GeoTagged values as a List will allow you some flexibility in your GeoEvent Service design.

...I used a GeoTagger to add a field GeoFenceNames containing the names of each GeoFence the received event's Geometry is INSIDE as a List. Note that I did not use the default DelimitedValue. If the received event's Geometry is within an area overlapped by two GeoFences, the List appended to the event by the GeoTagger will have GeoFence names at the first two index positions: GeoFenceNames[0] and GeoFenceNames[1]. (Note that the list's index is zero-based.)

By sending the geotagged event through a series of Field Calculator and Field Enricher processors, I can isolate the individual GeoFence names from the list and use those individual names as the key to the join needed to further enrich the events with attributes from a uniquely named polygon feature.

I have reviewed the need for supporting variable substitution for the IN and MATCHES operators within filter expressions with the development team and have created an enhancement request. No promises, but we will evaluate this against other work currently in our backlog and see if we can get it into a future product release.

Best Regards -
RJ