Latest Contributions by RJSunderman

The ArcGIS 10.3 GeoEvent Extension Patch 1 for Server, now available on the Esri Support site at the link below, includes a fix which I expect will address the issue you are describing. http://support.esri.com/en/downloads/patches-servicepacks/view/productid/66/metaid/2181  Specifically, we discovered that GeoEvent Services, published in the 10.3 release, which included filters with spatial conditions (INSIDE, WITHIN, CROSSES, etc.) caused the GeoEvent Services to disappear when either the GeoEvent product's service was restarted, or the GIS Server was rebooted. The upcoming 10.3.1 release will also address the issues addressed in Patch 1 above. - RJ ... View more

I've just verified for the 10.3.1 product release that this has been fixed. You will again be able to use a Field Calculator to produce a JSON String representation of a Geometry and write the result to a New Field Type:  String. When using the 10.3.0 product release, you will need to write your Field Calculator output to a Geometry field of type Geometry as illustrated above. You will probably also have to use a Field Mapper to make sure the 'Geometry' the processor has calculated is cast to a proper Geometry before attempting to update features through a feature service. The workflow outlined in the appendix of the product introduction tutorial works as documented for the 10.3.1 product release. Apologies for the frustration over this issue. - RJ ... View more

James - We've investigated and found that this is an issue with the 10.2.2 and 10.3 product releases. We've submitted a bug and will work to address this for the 10.3.1 product release. Thank you for bringing it to our attention. - RJ ... View more

06-24-2014 04:45 AM  Hei Jo wrote: Does anyone know how to change the geometry after receiving from Input Change the geometry how? At the 10.2.x product release you won't be able to do much with a Geometry event attribute. For example, you cannot reach into a Geometry to retrieve its coordinate values. At the 10.3 product release there will be a new type of processor available to incorporate into your GeoEvent Services which will allow you to buffer a received Geometry ... for example. Have you taken a look at the Introduction to GeoEvent Processor tutorial on our Product Gallery? Here's a link to a catalog of the product's available tutorials. In 'Appendix A' of the tutorial there is a section Using a Field Calculator Processor to compute a Geometry which shows how to generate a String representation (as JSON) of a "geometry", incorporating coordinate values from a received event into a Field Calculator processor's expression. Any changes you want to make to an event's "geometry" might need to follow that pattern. - RJ ... View more

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