I am attempting to only show events within a specific county from a stream of events that are statewide. I have created a service that I believe should do that:
The "Centre County Filter" as it is illustrated above does not pass any data at all. I should mention that the CoFence geofence contains all 67 counties in our state. When I change the filter to "CoFence/.*" it passes all events in the state, as I thought it should behave.
What might I be doing wrong to make this work incorrectly?
I should mention that I am using AGS/GEE version 10.21.
Thank you,
--Adam
I am able to delete the GeoFilter and then put in a new one with the same settings, and it works again for about 3 hours. When it happens, this is one of the log warning messages that I get:
org.apache.camel.component.direct.DirectProducer
No consumers available on endpoint: Endpoint[direct://DJs_TroopH:tcp-5564-in-04v-PSP_R4] to process: Exchange[JmsMessage[JmsMessageID: ID:OAOPRSAPP15V-1125-1408121996815-0:87:1:1:853245]]
Any ideas? Issues with GeoEvent Extension v10.2.1 that was overcome with 10.2.2?
Can you use the same GeoFilter in two different Services (models)?
Thanks!
--Adam
...also of note, getting this, but it doesn't make any sense...:
Field Calculator failed to assign value 'null' to the field 'ENR10' of GeoEventDefinition 'DJ_FieldReducer': Could not find a field with the name ENR10 in the geoEventDefinition DJ_FieldReducer
The field "ENR10" does not enter the equation until 2 steps AFTER the GeoEventDefinition "DJ_FieldReducer" is introduced. It is like my calculators are looking at the wrong GeoEvent Definitions.
Again, deleting and re-creating the GeoFilter usually fixes this for a few hours...
Can anyone in the GeoEvent Team or GeoEvent Community make any sense out of this?
Thanks,
--Adam
...edit to update the picture...
GeoEvent Extension - Geometry filter.
Still exhibiting the same behavior. All flow stops through the service (or model) - Delete the GeoFilter - Put another GeoFilter back in with the same parameters and it starts working again.
Any Ideas - or even a "we saw that and fixed it at 10.2.2"?
Thanks,
--Adam