nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Ellipse Calculator Processor workaround in GeoEvent?

AndersJensen

I have filed this BUG (BUG-000099124 ) some time ago, and I am wondering if anyone has a good workaround until someone fixes it? Basicly the problem is that Ellipses created as an output when using the Ellipse Calculator Processor have the same size, shape, and angle of rotation when the values of the 'Major Axis Source', 'Minor Axis Source', and 'Rotation Source' properties are set to 'Event'.

In my case I am collecting Lightning strikes, and they have a position that is within a given area described by an Ellipse. I would really like to visualise this Ellipse "on the fly" with GeoEvent, but this bug is stopping me for now....

Find more posts tagged with

Accepted answers

All comments

BrianLocke

Thanks RJ for your detailed reply. I had submitted two issues on github, one was for the original repo (depr) and the second was for the defense repo. I have went ahead and closed one last week and forgot to get the second--it has now been closed. Things are working as designed for the ellipse processor. One issue that was my fault was simply using 4326 for input and 2992 for linear unit (Meters to Feet) GeoEvents did not like this and was difficult to trouble shoot--I should have known better though. Another is that ArcMap and Pro both were using the minor diameter and major diameter as the processor was expecting minor radius and major radius. We're up and going and have been successfully generating proper ellipses. We're successful in using wkid EPSG 6556 for in and linear unit and EPSG 2991 for in and Linear Unit we've been pushing out to 4326 but this is no longer necessary for many reasons and will be going to 2992--our agency standard. Thanks for all of your help on this, same to Scott_Moore-esristaff‌

RJSunderman

Hey Brian -

First things first, let's make sure we're both looking at the same GitHub repository. The bug filed 02-Sept-2016 with Esri Support (BUG-000099124) was closed Dec-2017 with a remark 'Will Not Be Addressed'. Looking over its notes I see a link to an old Defense Solutions repo (no longer being maintained): solutions.arcgis.com/defense/templates/geoevent-extension

The repository currently being maintained is: defense-solutions-proofs-of-concept/blob/master/geoevent-components

I asked Hanoch Kalmanovich‌ to compile a *.jar for me for the Ellipse Calculator (Defense Solutions is no longer maintaining pre-compiled JAR with the Git resources). He compiled the custom processor using the 10.5.0 GeoEvent SDK. I was able to add the JAR to a 10.6 release of GeoEvent Server without a problem.

When I attempted to reproduce the issue I found that ArcMap's GP Tool (Data Management > Table to Ellipse) produced consistent results with the custom processor I had added to GeoEvent Server. Here are my reproduction steps:

1) Create the following non-spatial table in a file geodatabase and run the 'Table to Ellipse' tool

Notice that the coordinate values are in a state plane projected coordinate system.
I chose a location in the northern part of Minnesota to emphasize elliptic distortion, if that was going to be a factor.

2) Publish the Ellipse feature class (above) as a feature service so I could add the feature to a web map for display.

3) Configure the following GeoEvent Service. I'll try to attach an XML of the GeoEvent Server configuration in case you want to take a look at input / output configurations or GeoEvent Definitions ... but GeoNet is making that difficult.

The purpose of this GeoEvent Service is to broadcast a received Point geometry to a stream layer, use the Ellipse Calculator to compute an area-of-uncertainty from received event attributes (semi minor axis, rotation angle, etc.) and then stream the Polygon geometry to a second stream layer. Notice that I have configured the processor to expect the input geometry in the state plane coordinate system appropriate for the area of interest and to use that same SPCS for the spatial analysis. (The output is GCS WGS 1984; the stream service would have projected the geometry to this SR in any case.)

4) Add the two stream services as new layer to the web map displaying the Ellipse feature service (created using ArcMap's GP Tool) ... then HTTP/POST the following JSON to the GeoEvent Server's input to see the geometries processed by GeoEvent overlaid on the web map.

[

{
"center_x": 697182.8,
"center_y": 289173.3,
"wkid": "3595",
"semimajor": 1000,
"semiminor": 375,
"rotation_angle": 60,
"id": "WKID_3595",
"geometry": {
"x": 697182.8,
"y": 289173.3,
"spatialReference": {
"wkid": 3595
}
}
}

]

Notice the coordinate values are expressed in the state plane projected coordinate system (WKID 3595). The only difference between this JSON data and the data in the non-spatial table is that the semimajor and semiminor values have been cut in half ... since the Ellipse Calculator wants the radius and the ArcMap's GP Tool takes the full diameter.

I allow the Ellipse Calculator to overwrite the received Point geometry with the polygon it computes.

Looking at the two ellipse polygon geometries in the web map, they align almost perfectly. Zooming in there is a discrepancy of about 12 meters where the two ellipse's don't align perfectly:

I'm going to chalk that difference up to projection of the geometries. The ellipse created by ArcMap's GP Tool was created with a native spatial reference appropriate for the area of interest (WKID 3595) whereas the ellipse created by GeoEvent Server's custom processor was calculated in that coordinate system, but then projected to GCS WGS 1984 for broadcast by the stream service. Both were then projected, on-the-fly, by the web map to Web Mercator for display.

Hanoch can dig into the Ellipse Calculator's implementation in GitHub if we still think there's a defect there. But it looks to me like the processor is working as its contributor intended. Please let me know if you disagree.

Cheers --

Orderresults3.1.PNG

BrianLocke

Good eye, I should have uploaded the proper screen captures, got to the point of trying everything, input wkid is 4326, as is the output wkid. I do feel this is a units conversion issue. I am looking at that exact method and thinking of attempting a couple of tweaks, then I will re-run -maven install then try again in gep.

ScottMoore__Olympia_

Also, when you measure your output axes, which is correct? I am guessing the one from ArcGIS Pro/Desktop are, and the GeoEvent output is incorrect? If so, does it seem like a unit conversion issue? Here is the area of the geoevent code I would be looking at if you aren't already:

defense-solutions-proofs-of-concept/EllipseProcessor.java at a257842326f73f5691e56ba623c865146534c84e · Esri/defense-sol…

ScottMoore__Olympia_

Hi Brian,

Is your input really coming in as 3857 coordinates? I would think lightning strike data would come in with Lat/Long? What happens if you make your input WKID 4326?

BrianLocke

Yeah Attempting to use this for generating ellipses for lightning data as well, when we run this in ArcMap and compare the output from the processor -- getting two very different outputs. Thinking that there is a bug somewhere in the code for the GEO Ellipse Processor, also noticing that the linear unit is dependent on projected wkid for linear unit. We are using geographic 4326, then to projected 3857, then back to 4326--everything is in kilometer. Have started looking through the code on GitHub. See if anything pokes out at me. Pink is Ellipse done in ArcMap using table to ellipse and the Green is GEP Ellipse Processor

ArcMap table to ellipse GEP Ellipse Processor settings

have tried 4326 with both of these--not even close.

Join the Conversation

Signed in members can post, follow updates, and more. New here? Register a free account.

Quick Links

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.