I'm using Python 3.7 and ArcGIS Pro 2.8 (arcpy 2.8, py37_arcgispro_29734).
In working with data from a public source, I encounter issues with repair geometry (OGC validation). Fairly often I get a message of "ERROR 160189: The spatial index grid size is invalid." What's maddening, though, is that the error seems to be randomly occurring. Of the seven layers in the file, three sometimes have errors: one rarely (1 in 20), one usually (19 in 20), and one some of the time (12 in 20).
It is quite frustrating seeing that the same inputs (I'm wiping out the fgdb between trials and re-extracting from a single ZIP) are giving different results, and makes me think there is an issue in the RepairGeometry function (maybe a buffer problem or a race condition).
Attached is code to reproduce the issue including some statistics. Apologies that the original dataset is larger than ideal for a minimal example, but copying the problem features is hard (ArcGIS Pro UX problems being a separate issue altogether).
Download data; 10x loop: clean data directory except for zip file, extract zip file, repair the three problem layers, noting if they encountered errors; aggregate statistics and write that out to a file. Functions are used to make it easier to step through manually/interactively.
The table that is output shows True if errors were encountered, False if it completed smoothly.
Hennepin Dakota Scott 0 False False False 1 True True True 2 True True False 3 True True False 4 True True False 5 False True False 6 True True False 7 False True False 8 True True False 9 False True False
arcpy, requests, pandas
There are many multi-part geometries in here. The issues I've been seeing most frequently, though, are on features where there are differences between the Esri and OGC validity models (inner hole touches outer ring in one place).
The script you posted doesn't suggest anything, but I routinely convert multipart geometry to singlepart whether or not I am checking/repairing geometry. I would give multiparttosinglepart a prior to repair geometry to see if that improves things. Should you need to dissolve the geometries to simplify attribute representation, you can do it after the geometry is checked (and I would use both check geometry methods as well)
Thanks. I'll definitely look into that, as going to singlepart does seem to reduce issues. What surprises/irks me is that the results vary each time RepairGeometry runs on the same input data. That makes me think there are underlying issues in the RepairGeometry function (race conditions, memory/buffer issues). I would expect that, regardless of the success/failure of the repairs, that it would behave consistently each time.
Old but interesting... there are a number of issues with repair geometry, and the validation methods, but you identified one that may be a cause
try Integrate as well, self intersections (not necessarily crossings!) are tricky