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....

[NarelleChedzey]

Hi Karen, 

Can you perhaps answer a few questions about your scenario to help us track this problem down.   I am currently unable to reproduce on 2.8 final, 2.8.1 or even our current build.   

- Are you using file geodatabase or enterprise data?  If enterprise, what database platform (Oracle, SQL etc)

- What overload of EditOperation.Modify are you using?  Are you modifying geometry or attributes or geometry and attributes.   I tested using this overload passing only the layer, oid and geometry (No attributes). 

public void Modify(Layer layer, long oid, Geometry geometry, Dictionary<string, object> attributes = null);

- Is there anything special about your data; ie does it participate in a topology, utility network etc?    I was just using a polygon layer inserted via Map Notes. 

- I was using France as my region ensuring that the decimal separator was the comma.  Can you duplicate the problem with many different regions that use the comma as the decimal separator?

- Finally, maybe this is obvious, but have you verified via the debugger that the new geometry shape is a non empty geometry before passing it to EditOperation.Modify?  (https://pro.arcgis.com/en/pro-app/latest/sdk/api-reference/#topic8175.html)   

Thanks for any answers you can provide. 

Narelle

[KarenMeinstein]

Hi Narelle,

I am only modifying the geometry (no attributes).  The data is file geodatabase data (polygons) and there isn't anything special about it.  I was using German (Germany) as the region.  The problem occurred for me in 2.8, 2.8.1 and 2.8.2. An the problem is very consistent - it happens every time.  The exact same add-in works fine in 2.6 and 2.7.4.  

Yes, I have verified that the geometries aren't empty.  And I am using the same overload that you did - layer, oid, geometry.  I'm basically replacing the geometries in one feature class with geometries from another.  I'd be happy to show you what is happening if you want a demo.

Karen

[KenHartling]

Hi Karen,

I'm a product engineer with ESRI on the geoprocessing and geometry teams. I was asked to consult on a part of the issue you are running into. The trigger to the problem is the input feature class having 'bad' spatial reference properties.  I found that your xy Tolerance was set to 0. This causes the failure. If you recreate the feature class following the the instructions here - https://www.esri.com/arcgis-blog/products/arcgis-pro/analytics/geoprocessing-resolution-tolerance-an... you should be able to fix your feature class and avoid the failure.  

It would be very helpful if you could share how this feature class was created in this way with an invalid xy Tolerance Spatial Reference property.  If it was one of our tools... it would be something we would like to fix.

Thanks. Ken

[KarenMeinstein]

Hi Ken,

The feature class was created using Gdal (open source).  It was created with a region setting that uses a comma decimal separator.  When I just tried it with a decimal point instead of a comma region setting, the feature class was created with a non-zero XY Tolerance, so I guess that is why I am only seeing the problem when using region settings that use a comma.  So at least part of the mystery is solved.  What is still a mystery is that ArcGIS Pro 2.6 and 2.7 didn't seem to mind the XY-Tolerance = 0, but 2.8 does.  Was that a bug in 2.6 and 2.7 (that happily allows my software to work correctly in those versions)?

Anyway this is helpful information.  Now I know the problem IS caused by the region settings, but it a combination of how Gdal creates the feature class with those settings and how ArcGIS Pro 2.8 handles the incorrect Tolerance.  So now I at least have some idea how I might be able to solve this.

Thanks,  Karen

[KenHartling]

Glad I could be of help.

What is still a mystery is that ArcGIS Pro 2.6 and 2.7 didn't seem to mind the XY-Tolerance = 0, but 2.8 does.  Was that a bug in 2.6 and 2.7 (that happily allows my software to work correctly in those versions)?

Could be two things... are you 100% sure the feature class being created by GDAL back when you were using 2.6 and 2.7 was exactly the same with an xyTol of 0? The other thing is this may have been failing silently, risking a crash. We've been working hard to plug those sorts of holes in our code to avoid the possibility of crashing.

Thx. Ken

[KarenMeinstein]

Hi Ken,

I immediately went and tried this in 2.7 and it also created the feature class with XY tolerance = 0.  I don't have 2.6 convenient, so I couldn't try that, but I'm sure it will be the same because the gdal code is working independently of Pro, and it's the same gdal version and the exact same code.  Perhaps it might cause a crash, but so far that hasn't been the case - it seems to work fine - the only problem I've had is in 2.8.  It's unfortunate that the only way to fix this in Pro is by creating a new feature class.

Karen

[KenHartling]

Thanks for confirming.

Using data like may lead to other issues later in the workflow. Failures, crashes as well as workflows that appear to have completed without a tool erroring but resulting in bad analysis... having a process appear to have completed successfully when really it did not could be very dangerous to any analysis if there are not stringent checks to make sure everything worked correctly.  Every project should begin with an analysis of the validity of the data to be used (lots of doc on this), as well as an analysis at the end to determine if the analysis is working.

To get a better understanding of how spatial reference properties affect your analysis you can read more at the following:

https://pro.arcgis.com/en/pro-app/tool-reference/appendices/spatial-reference-and-geoprocessing.htm

https://pro.arcgis.com/en/pro-app/help/data/geodatabases/overview/the-properties-of-a-spatial-refere...

https://support.esri.com/en/white-paper/1301

Ken

[Wolf]

Hallo Karen,

 I will setup a test system with German language and region and try to reproduce your issue.  Can you tell me the projections that you are using for your geometries (both the feature class that you are modifying and the feature class from where you copy the data)?  Or maybe you can attach a sample dataset to your reply.

Wolf

[Wolf]

Hi Karen,

 I was not able to duplicate the issue you are seeing.  I attached my test add-in (2.8.2) and my test project.  You click a button on the test add-in it first creates a new feature and then updates the same feature on subsequent clicks.  Also, is it possible that the geometry you are copying into the modified feature is disposed by the time you are calling editOperation.Execute()?  Note that in my sample I use .Clone() to prevent this from happening.

// search the source for the matching parcel record
// copy only one polygon
Geometry parcelPolygon = null;

using (var cursor = sourceLayer.Search(new QueryFilter() { WhereClause = selectionSourceQuery }))
{
	if (cursor.MoveNext())
	{
		using (var parcelFeature = cursor.Current as Feature)
		{
			// note: cloning the gemetry makes sure that the 
			// geometry persists outside the context of the cursor
			parcelPolygon = parcelFeature.GetShape().Clone();
		}
	}
}