Latest Contributions by RJSunderman

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

If you are using the Push JSON to an external website outbound connector, yes, the connector's adapter will create a JSON representation of the GeoEvent it receives. At the 10.3.x and 10.4.x releases, the Push JSON to an external website outbound connector does not support the inclusion of query parameters in the URL. Beginning with the 10.5 release you can include query parameters in the outbound connector's URL. Variable substitution will provide value(s) for the query parameters based on the event record received by the outbound connector. Please refer to the following blog: Enhancements to the GeoEvent Server's outbound HTTP transport - RJ ... View more

Hello Morgan - I'm not sure I understand when you say "and put it into another service before i send it to the output" ... You should be able to include as many processors -- Field Reducer, Field Calculator, Field Enricher, etc. -- in-line to manage an event's fields, calculate new (or update existing) fields, and enrich events with data prior to sending then to an Output. There's only one GeoEvent Service in play; you shouldn't need another service to do what you are trying to do. Keep in mind that an Input receives event data as a byte-stream and is responsible for constructing a GeoEvent. The GeoEvent is the object being processed by the GeoEvent Service. If, for example, you do not want a recipient to see certain fields in the JSON they receive, you need to use either a Field Reducer to remove those fields from the GeoEvent or a Field Mapper to map the GeoEvent to a target output schema. The GeoEvent Service is not going to "manipulate the JSON or format of data". The Output will receive a processed GeoEvent and deconstructing it to build a JSON representation before sending the event data as JSON to the external website. - RJ ... View more

Thank you for the clarification.  If you are sending the data as MobileDeviceId,latitude,longitude then I would recommend creating a GeoEvent Definition with those fields in that order. Keeping in mind that every GeoEvent being processed must have a GeoEvent Definition which matches the event's schema. Comma-separated text being received via a UDP/Text Input must still have an Event Definition which specifies the event field names, data types, and field order. You will want to configure your Input to create a Geometry from the received latitude and longitude fields, and include a field of type Geometry in the GeoEvent Definition so that the Input has somewhere to put the Geometry it creates. - RJ ... View more

Hello - I'd like to confirm that you are using the revision of the Intro tutorial marked 'GEP 10.2 / Rev A' (cover page) released August 2013. You'll find these indicators at the bottom of each page of the tutorial. Are you using the initial product release (10.2.0) or the update (10.2.1)? Navigate to the Manager's version" rel="nofollow" target="_blank">https://localhost:6143/geoevent/manager/version.txt]version page to confirm this. The message indicating 'Configuration imported successfully' will only be displayed in your web browser's window for a few seconds before it disappears. If you missed the message, it may appear as if nothing happened. When navigating to the  Manager's [URL=https://localhost:6143/geoevent/manager/index.html]Monitor[/URL] page, do you see the SimpleGeoEventService, tcp-text-in, tcp-text-out, and file-out GeoEvent Service, Input, and Outputs listed? There is no harm in repeating steps 2, 3, and 4 on page 39 to attempt to re-import the WorkingWithFeatures_Config.xml product configuration file. If you repeat these steps and do not see the indicated message and service components, please reply confirming which product release you are using and the version and browser you are using to access Manger. - RJ ... View more