Latest Contributions by RJSunderman

Hello Simon - Generally speaking the out-of-the-box processors and adapters make a good faith attempt to convert data not presented in the ISO 8601 format, which looks like a date/time value, into a Date type object ... when the GeoEvent Definition specifies that a particular event field should be interpreted as a Date. Because the yahoo feed you referenced is passing its LastSampleTime as a quoted value, GeoEvent Processor will assume that the event field should be treated as a String ... so your initial assumption to modify the generated event definition to handle the LastSampleTime field as a Date type was correct. But there's one more step you have to take. Since the date/time is being supplied in an "international" format with the days value coming before the month value. In the inbound connector's configuration ... I was using a 'Poll an external website for JSON' input ... you need to specify a date/time mask. Expand the connector's Advanced properties and enter the following for the 'Expected Date Format': dd/MM/yyyy hh:mm:ss. This tells GEP to expect that any field of type Date should be parsed as days, months, years, hours, minutes, seconds with literal '/' between the date values and literal ':' between the time values -- rather than the American custom of months, days, years, hours, minutes, seconds. Now, because the provided date/time string does not include any time zone information, the GEP will assume that the received date/time is in the same time zone as the server processing the data. On my machine here in California the feed's provided value "30/06/2014 11:45:00" was parsed as June 30th 2014 at 11:45:00 AM, which is equivalent to Mon, 30 Jun 2014 18:45:00 GMT. When I push the GeoEvents into a GeoEvent cache and request a JSON representation of the event data, this is what I get: {     "Site": "210135-Brickmans Bdg",     "LastSampleTime": 1404153900000,     "RiverLevel": "1.123",     "FlowRate": "5.3",     "RainfallIntensity": " ",     "WaterTemp": " ",     "Conductivity": " " } The long integer, of course, is the GMT value of the date/time represented as milliseconds since the epoch ... consistent with the Esri Feature Services REST API. As you know, the out-of-the-box text adapter can create a text representation of this value, but it will automatically shift the value to your server's current time zone (e.g. 11:45:00 AM). If you need to, you can use a Field Calculator to add/subtract a number of milliseconds to shift the GeoEvent's UTC value from Zulu/GMT to Lima/Localtime, then use a Field Mapper to create a String representation of the value: "Mon Jun 30 11:45:00 PDT 2014". From there, if you really need report dd/mm/yyyy hh:mm:ss ... you'll have to use string functions to manipulate the string representation of the date/time. Hope this information helps - RJ ... View more

Nils - I apologize that we have not been able to respond to your forum post before now. I have reached out to a couple of specific developers on the team for help since your issue appears to be more related to custom adapter development than general product usage. Someone will get back with you as soon as possible. Thank you for your patience - RJ ... View more

Dennis - I apologize that we have not been able to respond to your forum post before now. I do not have any experience with the PI Integrator for OSIsoft and have referred your question to other members of the GeoEvent Processor team ... we will get back with you as soon as possible. Thank you for your patience - RJ ... View more

Hello Thomas - I apologize for not being able to respond to your forum post until now. Unfortunately you are running up against a known limit when using a Field Enricher (Feature Service) to enrich GeoEvents. That particular processor cannot be configured to update its internal cache of feature attributes more frequently than once every 60 seconds (1 minute). Transactions with an ArcGIS for Server feature service can be somewhat expensive from a real-time perspective. The design behind the enrichment processors was to enrich real-time events with information which was reasonably static. However, there is another form of the Field Enricher you might try. The Field Enricher (File) processor incorporates a system file watcher which monitors the file system and updates the processor's cache when changes to the enrichment file are committed to disk. Since you are comfortable using a JavaScript to push updated attributes into an enrichment source, maybe you could use a system file rather than a feature service to handle the secondary enrichment - once a vessel has been tagged as being INSIDE an established GeoFence? When you say "alter the value of the GeoFences via a JavaScript website and have the GEP react to the changes in real-time", keep in mind that a GeoFence, once imported into GeoEvent Processor, really only has a geometry and a name used to uniquely identifies the GeoFence within a category. While you could conceivably use the GeoEvent Processor's REST Admin API to adjust the GeoFence names and possibly the GeoFence category names of the GeoFences known to GEP, I don't think this would be recommended. I think you're on a better path using the GeoTagger to tag events inside an area (e.g. GeoFence) and then further enriching the events with attributes associated with that area (e.g. Feature service polygon feature or system file). Hope this information helps - RJ ... View more

Hello Adam / Chris - Thank you Chris for jumping in with advice on this ... My apologies to those of you who checked the product gallery prior to 22-March-2014, when new processors such as the Track Gap Detector were available in the released product, and could not find tutorial documentation. The tutorials on are updated periodically, as quickly as we can get to them. In Module 5 of the most recent update to the product introduction tutorial there is an exercise specifically covering the Track Gap Detector. The fundamental design behind the Track Gap Detector is to listen for events, cache received TRACK_ID values, and when a given track has not reported for a specified period of time - begin broadcasting notification events that expected data is no longer being received. The intended use was for vehicles or other assets in a well-known reporting group. The processor is not setup for monitoring an inbound connector to determine that a data provider itself has gone off-line. As Chris suggested, you could use a Field Calculator configured with a constant string for the processor's expression and add a generic TRACK_ID to all events from a particular data provider. I would configure the Field Calculator processor to create a new field, of type String, and apply the out-of-the-box TRACK_ID tag to the new field. Remember when working with string values to enclose literal strings in single-quotes in the processor's expression field. Hope this information helps - RJ ... View more

Hello Christopher - The Wikipedia article [url=http://en.wikipedia.org/wiki/GeoJSON]here[/url] gives a good example of different types of geoJSON. The GeoEvent Processor is able to parse and accept geoJSON containing "Point" data using the out-of-the-box generic JSON adapter. GEP cannot ingest "LineString" or "Polygon" geoJSON at the 10.2.x release. Can you indicate the URL you are using to query the GeoEvent cache for data? I think the formatting you are looking for is part of the standard REST API query syntax. For example, you might post the following geoJSON to a �??Receive JSON on a REST endpoint�?? inbound connector: {     "type": "FeatureCollection",     "features": [         {             "type": "Feature",             "geometry": {                 "type": "Point",                 "coordinates": [                     102,                     0.6                 ]             },             "properties": {                 "prop0": "value0"             }         }     ] } You could then direct the constructed GeoEvent to a �??Publish GeoEvents on a REST endpoint�?? output. At the 10.2.2 release, if you click to open an existing event cache output and review its configuration, you will see links for viewing the cache�??s contents as either �??Text�?? or �??JSON�?? as shown in the following illustration: [ATTACH=CONFIG]34970[/ATTACH] (Click to enlarge) If you browse to the cache�??s REST endpoint and append the formatting f=text you will get the following: Generated-GeoJSON-Example,Feature,"{""type"":""Point""}"," {""type"":""value0""}" If you browse to the same endpoint and append the formatting f=generic-json you will get a representation of the GeoEvent matching the illustration below. [ATTACH=CONFIG]34971[/ATTACH] Hope this information helps - RJ ... View more

Hello Tom - I apologize for not being able to respond to your post earlier. The easiest way to do what I think you are trying to do will be to leverage the Field Calculator and Java string functions available with the 10.2.2 product release. Given a block of JSON input: {     "Attributes": {         "name": "Some name...",         "date": "2/17/2014 15:31:45"     },     "Location": "31.555114:-117.458182:12.792526:10.000000:3.000000:0.000000" } You could design a GeoEvent Service something like the one illustrated below to find the index of the ':' delimiters within the event attribute string and then pull the substring found between those index values. [ATTACH=CONFIG]34963[/ATTACH] (Click to Enlarge) This is going to depend on your "latitude" and "longitude" always being found within the first two substring values of the Location attribute string. The output you should expect would look something like: [     {         "Attributes": {             "name": "Some name...",             "date": 1392679905000         },         "Location": "31.555114:-117.458182:12.792526:10.000000:3.000000:0.000000",         "IdxA": 9,         "IdxB": 21,         "Latitude": 31.555114,         "Longitude": -117.458182     } ] Hope that helps - RJ ... View more

Hello Samuel �?? I apologize for not replying sooner to your posts to the forum.  Thank you for your initiative in downloading and reviewing the source available [url=https://github.com/Esri/nmea-for-geoevent]here[/url] on GitHub. I noticed from the exchanges on GitHub that you are working with Vlad, who is the developer you want to be in touch with. I think that you are spot on with all of your observations. The NMEA specification is quite detailed and contains many different message sentence variants. What the GeoEvent Processor team put up on GitHub is only an example of how the product's SDK can be used to develop a custom adapter. As you've observed, the number of fields in a GPRMC message can vary. Because GeoEvent Processor requires a GeoEvent Definition to allow an adapter to parse a payload (e.g. NEMA message) from received event data, we would have to provide a potentially large number of event definitions if we were to advertise comprehensive support for all the different NMEA sentence variants. The initial offering only provides samples for three (GPGGA, GPGLL, and GPRMC). It appears, based on your message from 5-June that the validation code has a bias for �??North�?? and �??East�?? coordinate values. I�??m considering this a bug and will submit an issue against it. The validation logic which checks the number of fields, however, is tied to what the adapter plans to do with the data in those fields. I�??ve a feeling that if we were to simply relax the validation to allow GPRMC sentences with 12, 13, or 14 fields that other users might want to know why the adapter was ignoring data values in the extended fields, which goes back to what I was saying about needing a potentially large number of event definitions to satisfy a large variety of potential NMEA sentences. Thank you for your observations and the technical detail in your posts. If we do not immediately integrate your pull request on GitHub it is most likely because we want to maintain the NMEA adapter offering as a sample which folks can tailor for their specific devices (as you were able to do) rather than trying to maintain an adapter which supports "all possible" sentence structures. Best Regards �?? RJ ... View more

Hello Greg - You are correct that incorporating an outbound UDP connector, intended to send a keep-alive message to the external server, will not work if it is included in the same GeoEvent Service as the inbound connector used to receive and process input events from that external server. The GeoEvent Service would send an event to the outbound connector for every event received on the input (rather than the single keep-alive message you are looking to send). You might consider an approach similar to the one described in the Firing" rel="nofollow" target="_blank">http://forums.arcgis.com/threads/109558-Firing-a-GP-Service-Python-Script?p=391996&viewfull=1#post391996]Firing a GP Service/Python Script thread. If you developed a Python script which monitored the UDP socket along with the GeoEvent Processor, then whatever designates the "first" message received could trigger the Python script to send the necessary keep alive message back to the server. The Python script could then go to sleep and ignore any additional messages received as those are being handled by the GeoEvent Processor. Another option might be to use the GeoEvent Processor SDK to develop a custom inbound connector for Text/UDP which provided the acknowledgement / keep-alive you are looking for ... the inbound connector available out of the box does not include this capability. Hope this information helps - RJ ... View more

Hello Brooke - Sorry for the delay in getting back with you.  I've confirmed, unfortunately, that the adapter and transport behind the Send an email outbound connector will not accept HTML mark-up ... so you will not be able to add formatting to the e-mail messages you are sending out from GeoEvent Processor at current 10.2.x product release. After speaking with the developer, support for this can reasonably be added, and I have created a work item in our product backlog. I cannot promise that it will make the 10.3 product release, but we will work to see if we can make that happen. Best Regards - RJ ... View more

Hey Simon - Another approach recommended to me was to direct event data to a TCP socket which a Python script is monitoring. For example, if you had an out-of-the-box inbound connector polling a feature service for new features, the event data collected when new features were created could be sent to the Python script via an out-of-the-box TCP/Text outbound connector. The python script monitoring the TCP socket has a toolbox opened and when event data is received on the socket the script executes a model in the toolbox providing the event data as input. Using this approach you wouldn't need to develop any custom GeoEvent Processor components; the Python script would asynchronously run its geoprocessing model not caring where the event data came from. The drawback, I suppose, is that you'd have no way of reporting or handling any errors since there is no way to have the Python process callback on GeoEvent Processor. - RJ ... View more

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