In v2.8.1 EditOperation Modify method not working correctly with European comma decimal separator

[KarenMeinstein]

My company's software is used internationally so we test with different operating system (Windows) regional settings (i.e., various country specific numeric formats).  One section of our code uses the EditOperation Modify method to change some geometries.  This code works fine in ArcGIS Pro v2.6.x and v2.7.x with different regional settings, but in v2.8.1 when the regional settings are set to a region that uses a comma instead of a decimal point as the decimal separator, it no longer works correctly.  Specifically, the changed geometries end up with shape area = 0 and they disappear from the map.  If I go into the Windows 10 region settings and manually change the decimal symbol to a point, it works fine again, so the decimal separator is the problem.  Has anyone else encountered this?  Any work-arounds?  This seems to be a bug....

[Wolf]

No, you have to leave the editOperation.Modify line in the code, even so your 'sourcePolygon' will be overwritten in the callback.  The editOperation.Modify triggers the callback, the callback in turn then writes the 'untouched' sourcePolygon geometry through the geodatabase API. 
We know at this point that there is some problem with the sourcePolygon geometry, we don't know what the exact problem is yet.  The reason why you get an empty geometry is because EditOperation will 'simplify' every geometry before saving it in the geodatabase.  Apparently this 'simplification'  is the not working correctly and results in an empty geometry.  We are trying to find what the issue with the geometry is and also a method to fix it.  We tried some of the GP tools to fix the geometry but those had the same problem.   Anyways i will keep you updated on our progress, but for now that's the only workaround we have.  Also remember that your geometry still has an issue even once you write it directly into the geodatabase, so editing in Pro will not work for this geometry.

[KarenMeinstein]

Thanks Wolf,

Please keep me updated on what you find out about the data issue. These exact same geometries worked fine in v2.6 and 2.7, so I can't help but think that something in Pro changed in 2.8 to cause this issue. 

When I use your "call back" code in my application (as opposed to in the solution you sent, where I had it working), I keep getting the "Geometry cannot have z-values" error on the SetShape() method even though the data doesn't have z-values!?!?  Very strange..... and also a bit frustrating.

Thanks for your help.

Karen

[NarelleChedzey]

Hi Karen, 

Sorry if this is obvious again, but can you confirm that your geometry itself is not Z enabled prior to the EditOperation.Callback function  - https://pro.arcgis.com/en/pro-app/latest/sdk/api-reference/#topic8174.html

Even though your feature classes are not Z-enabled, and your source data from the feature classes are not Z-anabled,  some geometry routines may add the  Z flag to your geometry if you are doing certain manipulations between retrieving the geometry from the feature class and then storing it in the second feature class. 

Thanks

Narelle

[KarenMeinstein]

Hi Narelle,

I checked and the individual geometry DOES show HasZ = true, even though the feature class is not z-enabled.  Is there any way I can set the z flag to false?  

Karen

[NarelleChedzey]

Karen, 

The following code should create you a polygon without Z.   Because geometries are immutable, you need to use a geometry builder object, manipulate the Z flag and then obtain a new geometry.

Polygon polygonNoZ = null;
// needs to run on MCT
using (var builder = new PolygonBuilder(polygon))
{
  builder.HasZ = false;
  polygonNoZ = builder.ToGeometry();
}

However I would also recommend trying to determine which line of code turned your non Z-enabled source data into Z-enabled polygons.   

Narelle

[KarenMeinstein]

Thanks Narelle!  I will give that a try.

The geometry is z-enabled as soon as I retrieve it from the non-z-enabled feature class. If it's possible to save a z-enabled polygon in a non-z-enabled feature class, I supposed it could have happened when the polygon was initially created and saved.