Polygon Creation in Geoevent Server via Nested JSON

1488
6
01-03-2020 01:22 PM
ChrisSnyder3
New Contributor

I'm trying to create polygon geometry based on the following JSON data set coming from a Subscribe to JSON from External Websocket input and pushing to a Feature Service:     

"Vertices":[{"x":38.901939000001576,"y":-77.034143,"z":1.5230000698938966},{"x":38.901990000001575,"y":-77.03420799999999,"z":3.8682780703529716},{"x":38.901990000001575,"y":-77.034078,"z":3.8682780703529716},{"x":38.901990000001575,"y":-77.034078,"z":-0.803359929472208},{"x":38.901990000001575,"y":-77.03420799999999,"z":-0.803359929472208}]

What is the best way to accomplish this in GeoEvent Server?  Since the source data is nested and not in Esri JSON format, I'm assuming that I would either have to use the field calculator processor to create a Esri JSON array or create a new field for each vertex then combine them into a geometry field calculator?  If this doesn't work are my only options to reformat the data or create a custom processor?  Any help would be appreciated, p.s my team most likely doesn't have the time to reformat the data.  Thank you in advance! Jake SkinnerRJ Sunderman

0 Kudos
6 Replies
RJSunderman
Esri Regular Contributor

Hello Chris –

Essentially you need to perform some string manipulation to coerce the JSON array you have, which contains your coordinate value pairs, into a Esri Feature JSON string representation of a polygon geometry. You are correct that using (a few) Field Calculator processors is probably the best approach. I think comments in the thread How to switch positions on coordinates‌ show how to use Field Calculators to do what you need to do. You should not need to create a bunch of new attribute fields for each vertex and then somehow recombine these fields later. Please take a look at the linked thread and let me know if you have additional questions.

The Esri Feature JSON specification and samples for Point, Multipoint, Polyline, and Polygon geometries can be found in the ArcGIS Developers on-line documentation. You might take a look at the thread https://community.esri.com/community/gis/enterprise-gis/geoevent/blog/2015/08/01/can-i-use-the-geoev...‌ for examples of what an "Esri Feature JSON string representation" of geometry looks like, if you were to try using GeoEvent Simulator to send the data to GeoEvent Server.

Hope this information is helpful –
RJ

0 Kudos
ChrisSnyder3
New Contributor

Thanks RJ, I knew I was on the right track.  I was able to get the following:   

{"rings":[[[38.85976800000159,-77.049912,1.3000000705942512],[38.859774000001586,-77.04989,1.6823160694912076],[38.859762000001595,-77.04989,1.6823160704225302],[38.859762000001595,-77.04989,0.9197780704125762],[38.85977400000157,-77.04989,0.9197780694812536]]],"spatialReference":{"wkid":4326}}

However, ArcGIS Server is telling me that I have too many parts for the shape when I try to construct the geometry.  Does the JSON specification support z values for a 3D polygon? I thought it did.  I also have a z enabled polygon feature service.  Am I missing something here?  Does the specification only allow for 4 vertices? or a certain number of significant digits? Thank you.

0 Kudos
ChrisSnyder3
New Contributor

The error disappeared when I added a space before and after the colons.  But when I changed the output feature class the error came back... I switched the x and y coordinates as well but still can't get any polygon geometry to draw...   Here is the current data format,

{"rings" : [[[-77.049912,38.85976800000159,1.3000000705942512],[-77.04989,38.859774000001586,1.6823160694912076],[-77.04989,38.859762000001595,1.6823160704225302],[-77.04989,38.859762000001595,0.9197780704125762],[-77.04989,38.85977400000157,0.9197780694812536]]],"spatialReference" : {"wkid" : 4326}}

0 Kudos
EricIronside
Esri Regular Contributor

Hey Chris,

You might want to verify the output feature service you are pushing these events to supports Z (I know that has bit me a few times in the past). Also, if you think the events are being sent to the feature service, then check the logs there to see if there are any issues (I assume the message 'too many parts' above came from the feature service and not GeoEvent??).

0 Kudos
ChrisSnyder3
New Contributor

Hi Eric,

           Thanks for the suggestion.  My feature layer does support z and had the z default enabled to 0.  Yes, the too many parts response came from ArcGIS Server. I tested to see if the Geometry String I calculated is coming into the feature service through another "Test_Geometry" string field and what I've posted previously is what is coming into the feature service, so I know the data is coming in but ArcGIS Server will not build the geometry.

            I turned off the enable z default in the layer definition and the response I got was, geometry does not have z values or has null values.  The issue seems to be related to z values... But my JSON structure is correct, right?  Are there too many digits? Does ArcGIS not support z values that start with a zero such as 0.4?

              When I add the default z back, ArcGIS server says "the number of parts in shape is incorrect for its geometry type", yet the geometry type is polgyon! 

  I've been trying to solve this for awhile now and any help would be appreciated.  Thank you!

Update:  I changed the output connector to a feature service not published from the "Add a Feature" Output connector.  I tried publishing a new service from ArcMap via a new feature class with z enabled and z defaults enabled and still have the same issue.  For some reason, ArcGIS Server will not accept the data stream as a legitimate geometry.  I know RJ Sunderman‌ and Eric Ironside‌ have reviewed the JSON as valid.  I'm stumped as to what is going on...the issue seems to either be the formatting of the JSON string (I don't know what piece) or the data stream itself.  I read that sometimes the database/output from the Web Socket you are connecting to can have different bytecode translations such as decimal and comma.  I'm not sure if that is going on but the data is coming from a Redis Messaging web socket....I'll be contacting technical support this week as I have been unable to solve the issue.

0 Kudos
RJSunderman
Esri Regular Contributor

Chris

I don't know if this is a requirement for 3D geometry, but I always take care that the last vertex in my "ring" is the same as the first vertex so that the ring is closed.

Looking at the Feature JSON spec for Polygon, it seems their 3D example follows this "best practice". Note that the polygon JSON which follows has two rings, the first ring has 'M' values as well as 'Z' values, while the second ring has only 'Z' values:

( Click image to enlarge... )

Hope this information is helpful –
RJ

0 Kudos