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
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.
I am interested in the gist.
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?
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?
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.
Maybe RJ can chime in and note if I have anything wrong here.