Latest Contributions by RJSunderman

Hello Sindre - If the event data being brought into GeoEvent Processor includes coordinate values as attributes, and you want an inbound connector (e.g. TCP/Text or HTTP/JSON) to construct a geometry from the event attributes, the event must include a field which contains the WKID of the coordinate system associated with the event's coordinates. In your case, since the event coordinates are expressed in the "ERTS UTM Zone 33N" spatial reference (WKID: 25833), but that value has not been specified as an event attribute, you will need to use a Field Calculator processor to build a JSON string which a second processor, a Field Mapper, can then map into a field whose data type is Geometry. An example of this is included in the recently reworked Introduction to GeoEvent Processor tutorial. The exercise you are looking for is in the appendix and is titled:  Using a Field Calculator Processor to compute a Geometry. The tutorial can be found on our Product" rel="nofollow" target="_blank">http://links.esri.com/geoevent-gallery]Product Gallery. Here's a direct link:  Introduction" rel="nofollow" target="_blank">http://www.arcgis.com/home/item.html?id=265c334a47994dcc95e1bd57cf20e98e]Introduction to GeoEvent Processor. Hope this information helps - RJ P.S.  You might also want to take a look at the following forum thread:  Converting" rel="nofollow" target="_blank">http://forums.arcgis.com/threads/109721-Converting-Lat-Long-Coordinates-in-JSON-Feed-to-Geometry]Converting Lat/Long Coordinates in JSON Feed to Geometry.  I noticed that your data provider has formatted the JSON as an embedded list of lists ... you will need to specify some very specific syntax in order to reach into each event's JSON to retrieve the event values utm33x and utm33y. ... View more

Tom - If I understand the idea behind the sample, rather than restricting the Buffer processor to a static distance when creating a buffer about received events, the implementation allows a distance value to be retrieved from the incoming event. I'm assuming that the buffer GeoEvent Definition is something used internally by the custom Buffer processor ... so no, I would not specify 'buffer:radius' for the buffer distance I wanted the processor to use. Based on the user interface's behavior, it appears that specifying 'Constant' for the 'Radius Source' parameter allows you to specify a constant buffer distance; the processor then uses that static distance to buffer every received event. Specifying 'Event' for the 'Radius Source' parameter causes the UI to change such that an event field - presumably from the event being processed - is specified; the processor should then obtain the buffer distance from the specified event field. (I'm not sure why the label on the processor's property configuration page changes from Radius to Major Axis Event Field when toggling between 'Constant' and 'Event'...) If, for example, I have a GeoEvent Definition Flights-TcpText with event attributes FlightNumber, Origin Airport, Altitude, and BufferDist ... rather than buffering all flight positions by a fixed value (e.g. '1500' and 'Meters') ... I can allow each event to specify the desired buffer distance by specifying 'Flights-TcpText:BufferDist' as the field from which a more dynamic buffering distance can be retrieved. It appears that only the numeric value can be retrieved from the event however; you still have to select a unit of measure such as 'Meters' when configuring the processor. By the way - I had some trouble getting this to work. I had to stop/restart GeoEvent Processor to get the Buffer processor to recognize that I had updated my GeoEvent Definition to include a BufferDist with each incoming event. Then, at first, specifying 'Flights-TcpText:BufferDist' didn't seem to be working to retrieve the desired buffer distance from each event ... only specifying constant buffer distances worked. Later, after I had tried several things including changing the GeoEvent Definition's data type for BufferDist from Long to Double ... it started working. I'm not sure if changing the event's data type was the key to get it working however... Please be aware that we are working with a sample custom processor here. This was something prepared by one of the industry solution teams within Esri, not the GeoEvent Processor team, so I'm not working directly with the developer who implemented the processor. The GeoEvent Processor team is working to develop several new spatial processors for the core GeoEvent Product. These should be available with the upcoming 10.3 product release. Perhaps if we cannot get the sample custom processor to do what you need it to do, the processor being developed for the core product will work better for you. - RJ ... View more

Rob - In the driver's workflow, how is the point getting created which identifies the truck's current location? Mark is correct that if an AVL transponder is feeding vehicle locations to GeoEvent Processor, then it might be difficult to guarantee that the vehicle location being reported would be within a parcel boundary. However, if the driver were using some sort of in-cab application to select a location on a map, then it would be easy enough to have the driver click the rooftop of the house whose trash can was absent. That should allow a GeoEvent Processor setup which polls the feature service in which the point was created, discover (using a GeoTagger) that the point is inside a GeoFence (imported from a dataset of parcel polygons), enrich the geotagged event with an address retrieved from a String attribute field in the parcel dataset feature service, and then send a notification to identified stakeholders. The other approach, feeding the vehicle's location to an external reverse geocoding service, is something we have been asked to support. It is in our product backlog, but unfortunately it is not something that we have been able to assign to an upcoming development iteration. The invocation of external services, especially those with significant latency such as geocoding, tends to run afoul of the product vision - providing processors with minimal latency and avoiding bottlenecks which prevent high volume, real-time, event processing. If it is compatible with your workflow, I think an approach which integrates an application such as the ArcGIS Collector to create point features which GEP can then poll, geotag, and enrich would be better. You can find some additional information on how to do this [url=http://forums.arcgis.com/threads/100211-GeoTagging-several-fields-from-one-geo-fence]here[/url]. Hope this information helps - RJ ... View more

Hey Tom - Sorry for the delay in getting back with you. Where do the rangefans drop down values come from, and would you know why I am not seeing them? I don't have the Geoevent Server SDK installed. Is that required?  I believe the drop down values in the screenshot you provided are coming from the rangefans GeoEvent Definition. [ATTACH=CONFIG]34049[/ATTACH] When selecting 'Event' rather than 'Constant' for the 'Range Source' ... the 'Range Fan Field' should display a list of event fields for available GeoEvent Definitions. At least that is the behavior I see with my 10.2.2 instance of GeoEvent Processor. The list items you are referring to - rangefans:range, rangefans:bearing, rangefans:traversal, etc. - are different fields in the rangefans GeoEvent Definition. You should not need the GeoEvent Processor or ArcGIS for Server SDK installed to exercise the custom processors example. I initally thought that the screenshot in your message was one from your system, not a snip from the GitHub example page, so I prepared an instance of GeoEvent Processor 10.2.0, loaded the rangefan-processor-10.2.0.jar into the GEP framework and imported the GeoEventDefinitions-GeometryProcessors.xml configuration. I confirmed that the rangefans event definition was loaded, but when I tried to configure a 'Range Fan' processor in the Service Designer I did not see items in the event fields list for the rangefans event definition ... the only items in the list appeared to map to the incident event definition which gets installed with GEP. What release of GeoEvent Processor are you running? If you browse to the product's admin page for the installed processors ... what do you see for the RangeFanProcessor? 1) Browse to: https: //<host>:6143/geoevent/manager/version.txt to verify your version of GEP. 2) Browse to: https: //<host>:6143/geoevent/admin/processors 3) Click the JSON link at the top of the page and search for "name": "RangeFanProcessor" I've highlighted code in the following block you should look for: {     "name": "RangeFanProcessor",     "label": "Range Fan Processor",     "contact": "geoeventprocessor@esri.com",     "description": "Returns range fan derived from event center, range, bearing, and traversal angle",     "version": "10.2.0",     "domain": "com.esri.geoevent.solutions.processor.geometry",     "lastModified": "1393882661559",     "propertyDefinitions": [         {             "propertyName": "rangeSource",             "label": "Range Source",             "description": "Source of range Value",             "propertyType": "String",             "defaultValue": "",             "mandatory": true,             "readOnly": false,             "displayOption": "",             "dependsOn": "",             "allowedValues": [                 "Constant",                 "Event"             ]         },         {             "propertyName": "range",             "label": "Range",             "description": "Maximum distance from event for analysis",             "propertyType": "Double",             "defaultValue": "1000.0",             "mandatory": true,             "readOnly": false,             "displayOption": "",             "dependsOn": "rangeSource=Constant"         },         {             "propertyName": "rangeEvent",             "label": "Range Event Field",             "description": "Geoevent field containing range data",             "propertyType": "String",             "defaultValue": "",             "mandatory": true,             "readOnly": false,             "displayOption": "",             "dependsOn": "rangeSource=Event",             "allowedValues": [                 "rangefans:event_id",                 "rangefans:x",                 "rangefans:y",                 "rangefans:z",                 "rangefans:geo",                 "rangefans:range",                 "rangefans:bearing",                 "rangefans:traversal",                 "rangefans:date",                 "rangefans:geodef",                 "buffer:eventid",                 "buffer:x",                 "buffer:y",                 "buffer:z",                 "buffer:radius",                 "buffer:date",                 "buffer:geodef",                 "TrackGap:trackId",                 "TrackGap:gap",                 "TrackGap:lastReceived",                 "TrackGap:geometry",                 "Flights-TcpText:FlightNumber",                 "Flights-TcpText:StartTime",                 "Flights-TcpText:OriginAirportCode",                 "Flights-TcpText:DestinationAirportCode",                 "Flights-TcpText:AircraftType",                 "Flights-TcpText:Altitude",                 "Flights-TcpText:Longitude",                 "Flights-TcpText:Latitude",                 "Flights-TcpText:geometry",                 "Flights:FlightNumber",                 "Flights:StartTime",                 "Flights:OriginAirportCode",                 "Flights:DestinationAirportCode",                 "Flights:AircraftType",                 "Flights:Altitude",                 "Flights:geometry",                 "ellipses:eventid",                 "ellipses:x",                 "ellipses:y",                 "ellipses:z",                 "ellipses:geo",                 "ellipses:major_axis",                 "ellipses:minor_axis",                 "ellipses:rotation",                 "ellipses:date",                 "ellipses:geodef"             ]         }, ... Notice beneath the rangeEvent property that a full set of the GeoEvent Defintions known to GeoEvent Processor are displayed along with all of their event fields. To confirm this I stopped my 10.2.2 instance and spun back up my 10.2.0 instance ... and there they were. When I re-launched Service Designer I was able to see them when configuring a Range Fan processor. [ATTACH=CONFIG]34048[/ATTACH] Long story short ... try stopping and restarting your GeoEvent Processor then rechecking the admin page to review the processor's JSON definition. If the JSON lists the rangefans event fields as allowed values, you should see them when configuring a Range Fan processor. - RJ ... View more

Hello David - Please confirm the version of GeoEvent Processor that you are running. To do this, first sign-in to Manager then change the URL in the browser window from https://<host>:6143/geoevent/manager/index.html to https://<host>:6143/geoevent/manager/version.txt If the version information displayed resembles the following, you are running the initial release 10.2.0 which did not include the ability to design and publish GeoEvent Services from within the GEP Manager. Please consider upgrading to the latest product release 10.2.2 10.2.0.1155 10.2.0.1155 (10.2.0 Patch 1): Fixed - GeoEvent Manager - Chrome Browser issue of showing blank pages.  Using Dojo 1.6.2. If you are running either the 10.2.1 release or the 10.2.2 release - please reply back and we can investigate further. - RJ ... View more

Hello Tom - No, you should not need to build the source from the GitHub site. Not unless you find that the sample is not doing precisely what you want and you want to modify the source to customize the processor sample. If copying the JAR files extracted from the 10.2.x ZIP archive downloaded from the Gallery into the GeoEvent Processor's ...\deploy folder does not work, you might try explicitly adding them using the Manager: 1)  Launch GeoEvent Processor Manager 2)  Navigate to Site > Components > Processors and click 'Add Local Processor' 3)  Locate the buffer-processor-10.2.0.jar extracted from the 10.2.x ZIP archive downloaded from the Gallery 4)  Click 'Add' to add the selected JAR to the GeoEvent Processor framework You should see a message at the top of the Manager indicating that the custom processor was loaded successfully. If the BufferProcessor does not display in the Site > Components > Processors list after a few seconds, try refreshing the browser's display. I had to download and import the GeoEventDefinitions-GeometryProcessors.xml: 5) Browse to https: //github.com/Esri/solutions-geoevent-java/tree/master/data/configurations 6) Copy the GeoEventDefinitions-GeometryProcessors.xml file content to create a local XML file on your system 7) Navigate to Site > GeoEvent Processor > Configuration Store and click 'Import Configuration' 😎 Select the GeoEventDefinitions-GeometryProcessors.xml file and click 'Import' 9) Navigate to Site > GeoEvent Processor > GeoEvent Definitions You should see event definitions for buffer, ellipses, and rangefans listed. From there I was able to use the GeoEvent Simulator with a configured TCP/Text inbound connector to simulate events. I designed a simple GeoEvent Service incorporating a Buffer Processor. I mainly kept the default values for the processor. I specified 2500 meters as a constant buffer radius. I accepted the default WKID values for the incoming data (whose coordinates are WGS84), processor WKID (3857 is a spherical Mercator projection popular with web services), and output (project back to WGS84). I elected to send GeoEvents from the Buffer Processor to a GeoEvent cache, just so that I could review a JSON representation of the processor's output. [ATTACH=CONFIG]33939[/ATTACH] ... View more

Hello Tom - There are examples of a couple custom processors on the Esri" rel="nofollow" target="_blank">http://links.esri.com/geoevent-gallery]Esri Gallery along with the different connectors and product tutorials. I think the Processor" rel="nofollow" target="_blank">http://www.arcgis.com/home/item.html?id=a2f546a5cbb54e32a3218e5ded3f650a]Processor - Geometry Processors for GeoEvent Processor offering might be what you are looking for. - RJ ... View more

Hey David - I think the GeoEvent property you want to use is $RECEIVED_TIME ... not $ReceivedTime.  If you specify $RECEIVED_TIME as the Field Calculator expression, you should be able to time stamp each GeoEvent received from the Poll an ArcGIS Server for Features inbound connector with the server's current date/time. Correction:  When using a Field Calculator you need to use the functions receivedTime() and currentTime() as Vlad indicates below. Apologies for the misdirection.  - RJ I don't know that these "macros" are well documented ... the easiest way I know to find them is to review the list presented when configuring a filter expression. That dialog includes the attribute fields of known GeoEvent Definitions, known event field tags, and the GeoEvent property values (e.g. "macros") you can use in expressions. [ATTACH=CONFIG]33899[/ATTACH] - RJ ... View more

Hello Tom - The screenshot you took of the GeoEvent Definition generated by the inbound connector is indicating that location is a group containing two elements. The first element type is a String, the second element coordinate is a list of Double values. The "infinity" is how GEP indicates an element whose cardinality is "many". When coordinates are in a list, you need to specify the list index from which the coordinate value can be obtained. In your example you would retrieve the X Geometry Field from location.coordinate[1] and the Y Geometry Field from location.coordinate[0]. Note that I'm assuming the value 34.854503 is "latitude" and the value -117.087665 is "longitude". The list index is zero-based. Please refer also to the forum thread Is" rel="nofollow" target="_blank">http://forums.arcgis.com/threads/109508-Is-there-an-expression-for-converting-values-of-longtitude-and-latitude-into-a-point]Is there an expression for converting values of longtitude and latitude into a point. Hope this information helps - RJ ... View more

Hello Keren - An example of the functionality to which Mark is referring, Build Geometry From Fields can be found in 'Module 2' of the recently updated Introduction to GeoEvent" rel="nofollow" target="_blank">http://www.arcgis.com/home/item.html?id=265c334a47994dcc95e1bd57cf20e98e]GeoEvent Processor tutorial. Look on pages 26 and 27 in the exercise "Making Features Come Alive". If your coordinates are expressed as attributes within a group, as in Mark's example, you retrieve them from the JSON structure by name. If the coordinates are in a list, as illustrated below, you need to specify the list index from which the coordinate value can be obtained. {     "iss_position": {         "coordinates": [             -127.632425,             44.163747         ]     },     "message": "success",     "timestamp": 1400010196 } Given the JSON above, you would specify the X Geometry Field be taken from iss_position.coordinates[0] and the Y Geometry Field from iss_position.coordinates[1]. Hope this information helps - RJ ... View more

Hello Jordan - How many events per second is the GeoEvent Simulator you are using sending to GeoEvent Processor? Are you using the Update a Feature or the Add a feature outbound connector to update the feature service? Updating features can be expensive if the target feature service contains many thousands of features. This is because GeoEvent Processor must identify the feature to be updated by performing a full table scan querying for the feature's unique identifier to obtain the ObjectID of the table row before it can POST the update. There are a couple of things you might try to help narrow the scope of the problem: Reduce the number of events being sent to see if the problem is with data rate. Switch to use the Add a feature outbound connector to see the problem is with adding records vs. updating records. Specify a smaller number (50, 10, or even 1) for the outbound connector's Maximum Features Per Transaction parameter to see if updating the feature service with smaller batches helps. Check to make sure that there are no errors with the event data, such as a string which exceeds the maximum length allowed by the feature service or an integer value being sent which exceeds the range of the feature service's target field. You might also use the GeoEvent Processor's log to see how many milliseconds (or seconds) elaspse between GeoEvent Processor's POST to retrieve information and its POST to update the features. If there are any errors in these transactions, you might also find them in the log. First, from GEP Manager, navigate to the Logs page and click �??Settings�??. Select 'Debug' and enter the following logger item to debug: com.esri.ges.transport.featureService.FeatureServiceOutboundTransport. Don�??t forget to set this logger item back to ERROR, especially if you have thousands of events being sent to GeoEvent Processor. The logging statements generated at this level have the potential to produce log files which are quite large. If you edit the C:\Program Files\ArcGIS\Server\GeoEventProcessor\etc\org.ops4j.pax.logging.cfg configuration file you will see this logging setting persisted. If you have trouble using the GeoEvent Processor's Logging utility, you can always edit the configuration file directly (as an admin, since its under Program Files) to reset the logging level. Also, you might find it easier to view the log in a text editor. Look for the log file in the C:\Program Files\ArcGIS\Server\GeoEventProcessor\data\log folder. When reviewing the logs, you are looking for lines with the following logger entry:  com.esri.ges.framework.transport.featureservice-transport. Key phrases you will be looking for include: querying for missing track id Posting to url Response was At the debug level you should get a copy of exactly what is being sent/posted to the server. The query to get the object identifiers, for example, will look something like:   Posting to url : http:// �?� FeatureServer/0/query with parameters ... FlightNumber IN ('SWA1568','SWA510' �?� You should be able to see the JSON being sent to Server by each GEP transaction. You may need to copy/paste it into something like http://jsonlint.com/ to format it so you can read it. You can look at the timestamps on each log entry to get a feel for how long the different transactions with Server are taking. The illustration below is an example of what you want to dee in the logfile. Notice the latency in the last two DEBUG statements is about 325 milliseconds. If GeoEvent Processor is being fed a large number of events every second, it may be that transactions are taking to long and Server simply cannot keep up with the data being fed to it from GeoEvent Processor. [ATTACH=CONFIG]33629[/ATTACH] Hope this information is helpful - RJ ... View more

Hello Mark - If an Incident Detector processor has been configured to create "continuous" incidents, the management of the incidents is not handled by the individual processors in a GeoEvent Service. It is handled by an "incident manager" at the product level. So, once an Incident Detector processor has created an incident in response to a received event which satisfies the processor's opening condition, the only certain way to "reset" is to stop and restart the GeoEvent Processor - as you observed, cycling the GeoEvent Service which contains the processor is not sufficient. An ongoing, open, incident will only be closed if:  1) the processor"?s closing condition is satisfied by a received event; 2) the incident expires without update (depends on the Incident Detector processor"?s expiry time setting). The number of "open"� and "closed"� incidents the cache is allowed to contain is configurable. You would need to update the com.esri.ges.incidents.cfg file in the "�\GeoEventProcessor\etc product folder and restart GeoEvent Processor to do this. Reducing the allowable number of "open"� and "closed"� incidents does not "reset"� incident detection, but for testing and development, if you knew exactly how many unique incidents a given test would create, you might use this to force GEP to purge its cache between tests or test iterations. You also might find it helpful to use the administrative REST endpoint to look and see which incidents are currently in the product"?s cache, which are "open"� and which are "closed"�. Navigate to https://<server>:<port>/geoevent/admin/incidents in a browser window to view a snapshot of the incident cache. Also, please be aware that we recently identified a bug in which ongoing incidents, created by an Incident Detector processor, are orphaned when any property of any node in the GeoEvent Service containing the processor is changed and the GeoEvent Service is republished. The fault will manifest itself when the orphaned incidents expire; if the GeoEvent Service has an Incident Detector processor with the same name as the processor which originally created the incident, the "new"� instance of the processor (created when the service was republished) will be notified. The result is that an active, ongoing incident with the orphaned incident"?s TRACK_ID will be updated as closed, then updated again when a new event is received "� so you might see a "blip"� as the Geometry associated with the expired incident asserts itself if you are observing the incident Geometries on a map. We"?re working to address this with the 10.3 product release. Please let me know if you have any questions with the information above. Thanks - RJ ... View more

Hello Peter - I remember that work was done for the 10.2.1 release which changed how different Server connections were registered - ArcGIS Online (AGOL) being different than an on-premises / local ArcGIS for Server. This work was continued and additional changes were made for the 10.2.2 product release. Is it an option for you to try registering your AGOL connection using SSL with the latest product release (10.2.2)? - RJ ... View more

Hello Andreas - The text in the exception "Unable to intialize bean upgradeAction" suggests to me that something has run afoul such that GeoEvent Processor does not recognize a configurable element and is trying to "upgrade"� the element to work with the 10.2.1 product release you are running. Have you deployed any custom components? Added any connectors from the Gallery to your product? If you stop the Windows service which is running GeoEvent Processor, and then delete the files/folders in the following two directories, you should effectively reset the product. The files/folders you delete will be rebuilt when you restart the GeoEvent Processors"? Windows service.   C:\ProgramData\Esri\GeoEventProcessor   C:\Program Files\ArcGIS\Server\GeoEventProcessor\data 1) Delete everything in the product"?s configuration store. This is everything beneath the "�\Esri\GeoEventProcessor folder except the certs sub-folder. (You can delete certs as well, but you"?ll have to then go through the process of importing the GEP certificate as trusted.) These are all of your configured inputs, outputs, GeoEvent Services, GeoEvent Definitions, registered connections (Server and System Folders) "� etc. It is likely that something in here is what GeoEvent Processor is trying to "upgrade"�. 2) Delete all of the product"?s runtime data files. This is everything beneath the "�\Server\GeoEventProcessor\data folder. This removes the ActiveMQ cache, other cached data, the generated Java bundles "� etc. used by GeoEvent Processor at runtime. If you delete these two system resources, and there are no files in: C:\Program Files\ArcGIS\Server\GeoEventProcessor\deploy ... ... when you start the GeoEvent Processors"? Windows service it should be as if you just installed the product. You will need to give the system some time (typically about 30 seconds, but generally not longer than a couple of minutes) to build the Java bundles and create the runtime files before you will be able to launch and log-in to the GeoEvent Processor Manager. Please let us know if this resolves the issue. - RJ ... View more

Ananth - Thank you for the sample TAIP / RVP data and references you sent. It appears that the SierraWireless mobile gateway configuration utility - the "ACE Manager" - allows an optional TAIP ID to be specified on its GPS page. We will see what we can do to to extend the sample TAIP conector to: 1) Determine if this parameter has been included in the broadcast data; 2) Place the TAIP ID, if found, into the DeviceId field of the GeoEvent as a String. I will follow-up with you as soon as possible. Thank you in advance for your patience. - RJ ... View more