topic Re: 10.3 Problem with Input and GeoEvent Definition in ArcGIS GeoEvent Server Questions

10.3 Problem with Input and GeoEvent Definition

AdamRepsher — Mon, 15 Dec 2014 16:29:19 GMT

Is anyone else having problems with a Receive Text from TCP socket and GeoEvent definitions in 10.3?

I have a lightning feed that I have to establish a connection with as a client, so I have to modify the input a bit, BUT...

This has worked for me in 10.2.1 and 10.2.2, but now with 10.3, everything has stopped.

I narrowed it down to pre-defining the geoevent definition. If I format any of the fields as "Double" or "Integer", the input will not receive the feed.

Is anyone else seeing anything like this? Since this is not a clean install, maybe I need to delete everything in the GeoEvent folder sturcture and reinstall?

Thank you,

--Adam

Re: 10.3 Problem with Input and GeoEvent Definition

AdamRepsher — Wed, 17 Dec 2014 15:50:25 GMT

I got an answer from a GeoEvent employee:

My incoming feed has three numeric fields that contain a '+' sign if the number is positive. Earlier versions of GeoEvent Extension handled this. 10.3 does not. As I understand it, this was taken out because of different locales needing the ability to set their numeric formatting to their standards.

Esri staff is looking into a workaround for me. I will post the gist of it if anyone is interested.

Re: 10.3 Problem with Input and GeoEvent Definition

Chad__Admin_Quinn — Tue, 13 Jan 2015 13:41:49 GMT

I am interested in the gist.

Re: 10.3 Problem with Input and GeoEvent Definition

PhilipGlasner1 — Tue, 13 Jan 2015 16:56:18 GMT

I am experiencing similar problems. Using the same csv file GeoEvent Processor 10.3 does not create XY points while GEP 10.2.2 does. I am also facing problems that floating numbers are not interpreted correctly. Any solutions to these problems?

Re: 10.3 Problem with Input and GeoEvent Definition

AdamRepsher — Fri, 10 Jul 2015 17:30:10 GMT

Philip,

For us, the problem was simply the fact that this data feed was putting a '+' sign in front of the positive number. This forced the program to think it was text in the default locale. RJ Sunderman created a workaround.

We brought any potentially POSITIVE number into GeoEvent and defined their field as a string. Also created a field for the conversion to a number and formatted it as Double for easier processing. You will see why in the next step.
Field Calculation
a. Remove any + from the string with the expression in the following pic...
b. Place the result into the Double field.
We then had to make an output and input for the middle of our model (Service) because the input is the only method that you can convert X and Y fields to geometry.

Maybe RJ can chime in and note if I have anything wrong here.

Re: 10.3 Problem with Input and GeoEvent Definition

AdamRepsher — Fri, 10 Jul 2015 17:49:21 GMT

Sorry Chad. I forgot to do this. See my recent reply to Philip.

BUT...
I have not completely gone through the solution in the Philip response because we had another issue with the incoming data format. The date/time stamp was not ISO 8601 compliant, so we had to append the zone ourselves in another calculation:

replaceAll(EVENT_DT_UTC,'[.][0-9]+$','GMT-00:00')

The result had to go to a json-websocket-out and back in through the json-websocket-in, to get the time/date into a DATE formatted field and create the geometry from X and Y text.

Does all of that help you at all?