Visible precision errors when clipping using AGSGeometryEngine.difference

[frankm]

Hi,

I am trying to figure out an issue we are having relating to clipping overlapping geometries in features. When we add new features with geometries, we allow the user to "clip" the new geometry with others that overlap the new geometry. We use AGSGeometryEngine.difference to create a new geometry and then store the new feature. However, the resulting geometry is then adjusted by the SDK (I believe the issue could be the featureTable.addFeature-method "simplifying" the geometry when saving, the docs mentions this).

The end result is a visible error in precision with either overlap or gaps between the geometries. Does anyone know of a way around this or are we hitting some precision limit in the spatial reference being used here? It only happens when being in "online" mode, if we work on offline-maps, all is well - until we go online 🙂

I had a theory the problem was we were comparing already saved geometries with unsaved, and that if we created the new feature first, then clipped it would work better, but it does not seem to matter.

[DiveshGoyal]

Can you provide a screenshot or two showing the problem?

I'm a little puzzled that things work correctly offline, but then you see the problems when you're connected.

Can you try setting the map's load settings to disable feature tiles and see if that makes a difference?
My guess is that the issue is related to the usage of feature tiles to display the layer in connected mode. The geometries in feature tiles are quantized for various scale levels to get the most performance, perhaps this is causing the problem which we'd need to investigate further

[frankm]

Here are some screenshots of what I am seeing.

I thought I saw an improvement when zooming in before clipping and then back out after, but that had no effect.

The new area in red, will be clipped by the blueThe new area is created and I just zoomed in on the edge in the green area

[DiveshGoyal]

What spatial reference is your map using, and what spatial reference is the layer/service published in?
Can you provide a small project that reproduces this problem? You can DM me directly if you don't want to share that publicly

[frankm]

As far as I can tell we are using 25833 on the map and its operational layers. What I have discovered though is that if we access the data via a webmap/portal/item the clipping seems to work as intended, but if we access the service directly via url the problem appears. I will test this now and try to make a test service/layer publicly available and write a simplified app to test it. I will send you an update when I have something.

[frankm]

Just a small update. I got the demo app working by setting up a empty map and just inserted a feature layer by URL on a public feature layer. I had hoped this would show the error but actually it does not. So far I have a test app using a web map, not having the issue and a test app without a web map just using a feature layer directly, still fine.

I think I will halt it there and shift focus away from the clip operation itself and rather look at how the map is set up in the problematic apps, it could very well be that the problem is not where I thought it was after all. Well, I'll post an update if I figure it out. Thanks for the help so far.

[DiveshGoyal]

Ok. Let us know what you find. 
Also make sure that feature you are using to clip the sketch geometry is loaded (you cn use AGSArcGISFeature.load() to load it). This will ensure the feature has the full resolution geometry for cases when feature tiles are being used to optimize the display 

[frankm]

I have now tried to load each feature in play here, but it seems to have no effect. After the operation we do a featureTable.update with the feature getting the new geometry and I see that the following is mentioned in the method description:

"Updating a feature that contains an @c AGSGeometry
causes the geometry to become simplified. This may change a single part geometry to a multipart
geometry, or round off X, Y, Z, and M coordinate values that are above the resolution set by the
@c AGSSpatialReference."

Could this be the root cause?

[frankm]

Small update to the issue, I am revisiting the issue and I have verified the problem also occurs working on web maps. I will do further testing.

[frankm]

Curious update: Just noticed that if I do a clip (using difference) extra it seems that the object that used to have the gap/overlap issue is moved correctly. I will examine this further. This is just weird. And to be clear: the gap/overlap issue is an issue because the data is processed later on the backend so overlap is flagged as an error, so this is not a visual bug.