Latest Contributions by RJSunderman

Hey Elias - Can you provide me a sample of how the date/time values are being sent to GeoEvent Processor? Are you interested in receiving a string value such as "14-7-2012 02:30:45 PM" and allowing an input connector to use an Expected Date Format mask such as dd-M-yyyy hh:mm:ss a to interpret the string as a Date ... July 7, 2012 14:30:45 in this case ... and then then pull the Month portion out as a numeric (e.g. 7 for July)? We might be able to use substring( ) or a Regular Expression to pull a portion from a date/time String which represents the month, if the date/time is brought in as a String. But if you need the Input to convert the value it receives to a Date, we may have trouble trying to get the month out of the Date object. - RJ ... View more

Hello Elias - I think there was an issue with using non-spatial tables as the source of event enrichment at the 10.2.0 release. The Field Enricher processor was assuming that the target table would have a Geometry field ... which of course non-spatial tables do not. I created a mock-up of the scenario we have been working with using my build of 10.2.1 and didn't have any problems first GeoTagging events with the GeoFence(s) they were inside, then using a Field Calculator to pull the name of a specific GeoFence from the List of tags and sending that event through a series of Field Enrichers ... one enriching the event with a String from the Feature Service's Feature Layer, and one enriching the event with a String from the Feature Service's Table. Here's how I configured my GeoEvent Service (click to enlarge thumbnail): [ATTACH=CONFIG]32930[/ATTACH] [ATTACH=CONFIG]32931[/ATTACH] [ATTACH=CONFIG]32932[/ATTACH] My Feature Service has a Feature Layer at layer index 0 and a non-spatial table at layer index 1: [ATTACH=CONFIG]32933[/ATTACH] - RJ ... View more

Hello Thomas - Using only out-of-the-box processors, this could be tricky. By design most of the configurable filters and processors used in a GeoEvent Service do not maintain any sort of cache, so your GeoEvent Servcie will never know, for example, how many events for a vehicle with the license plate ABX-339 have been received. We might be able to work around this, though, without having to use the GeoEvent Processor's SDK to develop a custom processor. Do your events have unique track identifiers? If so we might develop a creative GeoEvent Service which polled its own output feature service to update a non-spatial table containing event statistics with attributres being maintained on the base features. [ATTACH=CONFIG]32896[/ATTACH] Consider the illustration of the GeoEvent Service above (click to enlarge the thumbnail). The event flow goes something like this: An event is received on a GEP input connector's REST endpoint - The input connector constructs a Geometry from the event's attribute fields  - A Field Reducer is used to remove the Latitude and Longitude fields from the event  - The constructed Geometry is retained and the event is now "flat" (complient with an Esri Feature Service)  X  A Field Enricher joins the target feature service's non-spatial table to the event - If field enrichment succeeds because a field named EventCount is found, a Field Calculator will increment the integer in the joined field and write the incremented value back into the enriched event. The enriched event is then written out to the target feature service's feature class.  - If the field enrichment fails because the target feature service's non-spatial table has no EventCount for the event with the received TRACK_ID, then a different Field Calculator ... the one named ResetField ... writes a hard-coded '1' into a new field named EventCount.  X  In either case, a single feature in the target feature service's feature class is updated with the received event which is tracking a count of the events received for that TRACK_ID. X  A separate input connector is polling the target feature service's feature class, and when it sees a feature whose DateTime value is greater than the last date/time a feature was added/updated ... the "new" feaures are retrieved and the EventCount from each feature is transferred to the target feature service's non-spatial table. Depending on the rate at which you are receiving new events for a given track, I've observed this approach working. My tests were only preliminary though ... for example, I was making sure that the second input connector always had a chance to poll the feature class to get updated counts for the events received before new events were POST'ed to the other input connector's REST endpoint. I'll try to make some time to work with this approach some more and identify any faults. Please reply if you are able to make this work or have any questions. - RJ ... View more

Hello Brian - Additional references which may be helpful:   Ports used by GeoEvetn Processor:  Thread:" rel="nofollow" target="_blank">http://forums.arcgis.com/threads/105789-Rest-Port?p=377617&viewfull=1#post377617]Thread: REST Port   Windows command to list ports currently in use:  netstat -o -a Run the latter command from within a Windows command console window to see which ports are in use by which PID (program identifiers) on your system. Like Mark said, on my local system, I usually find no conflicts when using ports in the 5500 - 5600 range for TCP/Text input. - RJ ... View more

Hello Elias - While we do not have an inbound connector available for retrieving data from an RDBMS table, we do have an out-of-the-box input Poll an ArcGIS Server for Features which will poll a feature service for features. This is perhaps a subtle distinction since, yes, a feature service is backed by a feature class whose data table is in an RDMBS ... but the feature service provides the interface we've developed the inbound connector to use. I've attached an illustration of how you might configure this type of input. In the illustration, notice that I have specified the registered connection to my local ArcGIS for Server (RSUNDERMAN_AGS), the services folder (GEP_Forum), and the name of the feature service I want to poll (USGS_Earthquakes_LastHour). That feature service has a layer, also named USGS_Earthquakes_LastHour, which contains the features I will be polling. I had previously imported a GeoEvent Definition from this feature service, so I specify that the input should not attempt to create one, but should instead use the one I imported named USGS_Earthquakes_LastHour. Evidently I wasn't feeling very creative with my names. 🙂 The Refresh Interval is expressed in seconds. So this input would poll the feature service every 10 seconds for data. The Get Incremental Updates parameter was changed at 10.2.1 to allow configuration based on timestamp (as shown) vs. OBJECTID (which is your only option at 10.2.0). I've left the defaults beneath Advanced unchanged ... particularly the option to not delete features polled by GeoEvent Processor. Please let us know if this input will do what you need. [ATTACH=CONFIG]32882[/ATTACH] Thanks - RJ ... View more

Below is a list of ports used by the GeoEvent Processor which identifies the configuration files you can use to change the defaults. (Click thumbnail to enlarge / open in a new window) [ATTACH=CONFIG]32748[/ATTACH] ... View more

Thank you Rob - Yes, I have confirmed that release 10.2.1 of GeoEvent Processor has a bug which prevents the Filter properties window from displaying when Manager is opened in an IE 11 browser. This issue has been addressed in the 10.2.2 release which should be available publically later this month. - RJ ... View more

Hello Elias - I am not sure that what you are trying to do with the Incident Detector processor is a good fit with the intended use of that type of processor. I would like to include some background I think might be applicable to what you are trying to do. If I am diverging from your need or objective, please help me to focus both what you are trying to accomplish and why. Assuming that the vessel data being sent into GeoEvent processor is being enriched with an identifier of a GeoFence the vessel is currently INSIDE, and one or more attributes from the GeoFence's original polygon (I think you referred to these as "reasons" a vessel is prohibited from entering an area) ... you want to use an Incident Detector processor to generate an alert which contains the vessel's name / track identifier, prohibited zone identifier, and prohibition reason / regulation? Do you really need to use an Incident Detector? If you do not need to track and report the duration of the vessel's violation you could filter the vessel GeoEvents for those INSIDE a prohibited area and then select and send information from GeoEvents which survive the filter to a notification output (Email, SMS Text, or update an "alerts" feature service). A second filter identifying vessel GeoEvents NOT INSIDE a prohibited area could then update a feature service with all of the vessels currently in compliance. An Incident Detector is intended to act as a monitor. The events output from this type of processor are derived from the events it receives. The only information an incident is supposed to share with its originating event is the TRACK_ID.  An Incident Detector is primary used is to create an incident, track the incident,  and the incident's duration -- independent of the GeoEvent whose attributes or spatial proximity triggered the incident. An expected workflow might be something like: A vessel enters a prohibited area A GeoTagger processor tags the event with the name of the zone the vessel is violating A Field Enricher processor enriches the event with the reason the zone is not to be entered An Incident Detector processor generates and begins tracking duration of the incursion A notification is output to inform an analyst that a violation has occurred. An analyst, receiving an Email, SMS Text, or observing an "alert" in a table widget or map display within an application would be expected to take note of the TRACK_ID in the incident and query to locate the related feature. The analyst would use a client application identify the vessel which has entered the prohibited area and open that feature's attribute table to identify the reason behind the violation. Because the GeoEvents containing the vessel information and those containing the incident information are separate events, they cannot be mapped or joined together within a GeoEvent Service. Both events would need to be persisted out to a table (e.g. a feature class) which could then be polled as part of a second GeoEvent Service to enrich the incident with data from the vessel. But doing so creates a race condition ... there is no guarantee that the two different GeoEvents will be written out to their tables such that a second GeoEvent Service will have the features it needs to do its job at any given instant. If you truly do need an Incident Detector processor, because you do need to track the duration of a violation - or need to leverage something else the Incident Detector is providing you - perhaps you could look at using a Make Query Table or similar tool from the Data Management toolbox (outside of GeoEvent processor) to handle the necessary join of a vessel feature with its corresponding incident. - RJ ... View more

Hello Jeremy, What you are observing was actually implemented by design. You might say that the spatial operators enter and exit are actually meta-operators - because they refer to a cache of prior events to determine the most recently received event"?s spatial relationship to the GeoFence being considered. A simpler operator, such as inside or outside, does not need to refer to a cache of prior events; at any given instant an event is either inside or outside a given GeoFence. But if we want to answer the question of whether the event has entered (vs. exited) a GeoFence, we need to first know if its last reported position was outside (vs. inside) the GeoFence. Based on customer feedback during initial product development a decision was made that, when an event"?s prior position is not known, the enter spatial operator will report an event has "entered"� a GeoFence if the event is simply inside the GeoFence. The feedback was that customers did not want to miss an opportunity to GeoTag an event as being inside an area of interest only because the event"?s prior position was not known. The logical opposite is that the exit spatial operator, when an event"?s prior position is not known, will report an event has "exited"� any GeoFence that the event is not inside. The obvious downside to this is that the first event received for a given track will be outside nearly every - and potentially all - known GeoFences. However, once an event"?s prior position along a track is known, the exit spatial operator will report an event has "exited"� a GeoFence only when the event was last inside the GeoFence and is now outside the GeoFence. There are a couple of points above I would not want you to overlook. When I say that the spatial operators enter and exit refer to a cache of prior events, this implies that the GeoEvent Service containing the GeoTagger processor has not been rebuilt. If you change any of the specified properties of any of the nodes (Input, Output, Filter, or Processor) within a GeoEvent Service and then publish the changes - or stop and restart the GeoEvent Processor - the GeoEvent Service"?s cache will be cleared and the service will behave as if it has never before received a position for a given track. Which brings up the second point: If the GeoEvent Definition used to interpret a specific class of event data does not have a TRACK_ID tag on a field which can be used to uniquely identify events occurring along a track, the spatial operators enter and exit will never know the last reported location for an event and will therefore always behave as if this is the first reported event for a track "� in which case you would expect a GeoTagger processor configured to tag events which exit a GeoFence to tag every received event with the name of every GeoFence the received event is not inside. We are looking at implementing a switch which will allow an analyst to specify whether a GeoTagger should behave as described above - that is, default to inside and outside when an event"?s prior position is not known "� or whether the processor should strictly report "entry"� and "exit"� only if a prior position is known and indicates that the event was previously outside (for "entry"�) and inside (for "exit"�). At the 10.2.1 / 10.2.2 releases, the only work around will be to ignore the tags applied to the first received event for a track since that event"?s position is needed to establish a history for enter and exit determinations to be valid. Hope this information helps - RJ ... View more

Mark - You might find some help with what you are trying to do if you review the following thread: Overlapping" rel="nofollow" target="_blank">http://forums.arcgis.com/threads/105319-Overlapping-geofences-with-different-attributes?p=376287#post376287]Overlapping geofences with different attributes - RJ ... View more

Morgan - You might find some help with what you are trying to do if you review the following thread: Overlapping" rel="nofollow" target="_blank">http://forums.arcgis.com/threads/105319-Overlapping-geofences-with-different-attributes?p=376287#post376287]Overlapping geofences with different attributes - RJ ... View more

Hello Elias - In general, if you want to use a GeoTagger to identify a GeoFence a event's Geometry is within, and then use a Field Enricher to enrich the event with attribute information from the feature service used to create the GeoFences ... the individual GeoFences must not overlap. A description of why this is the case is presented in the thread Field" rel="nofollow" target="_blank">http://forums.arcgis.com/threads/104737-Field-Enricher-with-Multiple-Matches?highlight=GeoFence+overlap]Field Enricher with Multiple Matches. There is a work around, which you can scale depending on the number of potentially overlapping GeoFences. Please click to open the following illustration example" rel="nofollow" target="_blank">http://forums.arcgis.com/attachment.php?attachmentid=32575&d=1395956685]example GeoEvent Service, also attached below. In the GeoEvent Service illustrated above 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. Each Field Calculator processor is able to handle the exceptional case in which there is no ordinal value at a specified index. For example, if the GeoFenceNames list contains only two identifiers, the expression GeoFenceNames[2] in the GetGeoFence3 processor will handle the exception by terminating event flow through that parallel branch. The other two branches will succeed in retrieving GeoFence names using the index values specified in their expressions, and the enrichment in-line with those two branches will succeed. The Field Reducer in the illustration is optional. I'm using it to remove the Longitude and Latitude received with the original event and the GeoFenceNames List added by the GeoTagger ... to simplify the event and remove redundant data before it is sent to the output. The TCP/Text output will receive one event for each named GeoFence in the GeoFenceNames List; the list tagged onto the event by the GeoTagger identifing all the GeoFences the original event's Geometry is within. The solution illustrated is not perfect -- it will only handle up to three overlapping GeoFences. But you can see, I think, how you could scale the workaround to handle a reasonable maximum number of instances of overlapping GeoFences. You will have to evaluate the performance of this workaround in your environment against the complexity of your polygon feature service geometries and schema as well as the rate at which you are feeding data into GeoEvent Processor. Hope this information helps - RJ ... View more

Those interested in this topic might want to check out a recent offering from one of our partners, CompassCom, on the Partner" rel="nofollow" target="_blank">http://www.arcgis.com/home/group.html?owner=GeoEventTeam&title=ArcGIS%20GeoEvent%20Processor%20Partner%20Gallery&content=all]Partner Gallery. From their press" rel="nofollow" target="_blank">http://www.satnews.com/story.php?number=1591767694]press release: "CompassLDE interfaces with GPS hardware from Trimble, Motorola, Sierra Wireless, CalAmp, and any GPS-enabled smartphone or tablet computer. CompassLDE may be purchased for on-premises operation or accessed as a service hosted by CompassCom, a provider of best-in-class mobile resource management solutions since 1994." You can find a link to the Partner Gallery as well as the Product and Community Galleries on our Real-Time" rel="nofollow" target="_blank">http://pro.arcgis.com/en/share/geoevent-processor/]Real-Time Data Feeds and Sensors resource page. ... View more

Hello Brian - I was unable to reproduce this with my build of GeoEvent Processor 10.2.1 using either Chrome Version 33.0.1750.154 or Internet Explorer 9.0.8112 (update 9.0.25). Can you let us know which browser and version you are using? Thanks - RJ ... View more

My apologies Brandon - The link I copied into the previous post took you to the REST Administration tutorial. The correct link is: Introduction" rel="nofollow" target="_blank">http://www.arcgis.com/home/item.html?id=265c334a47994dcc95e1bd57cf20e98e]Introduction to GeoEvent Processor. You will find a section titled "Use GeoEvent Simulator to simulate an event stream" on page 26 of Module 1. The tutorials have been recently reworked to make them more approachable. The material is now presented in five separate modules with a new appendix with some tips and tricks. Please let me know if you find this helpful. Thanks - RJ ... View more