Hole lies outside shell and arcpy

[irfanlatif]

hi there,

In my workflow, I am converting our mapset in ESRI (ArcGIS 10.7) FileGeodb (topological clean and no geometry error) to Postgis.

In PostGIS I am getting a geometry validation error  "Hole lies outside shell" and I am thinking how to find this error using arcpy.

Here is polygon where I am getting this error.

MULTIPOLYGON(((18.580058 54.387989,18.580688 54.387949,18.581455 54.38745,18.58103 54.387236,18.581292 54.387046,18.581613 54.387193,18.581928 54.387025,18.581818 54.386618,18.581261 54.386702,18.580977 54.38657,18.581072 54.386234,18.580021 54.385724,18.579978 54.386042,18.580181 54.386148,18.579153 54.386818,18.579249 54.386861,18.578992 54.387036,18.578708 54.386886,18.578114 54.386992,18.57806 54.387864,18.578553 54.388089,18.580058 54.387989)),((18.580058 54.387989,18.58009 54.388582,18.580315 54.388695,18.581319 54.388631,18.580058 54.387989),(18.580058 54.387989,18.579111 54.387517,18.579764 54.38739,18.580048 54.387528,18.580058 54.387989))) 

I know st_makevalid() will correct this problem. What I want, is to correct my source data which is in FileGeodb.

any suggestions?

[JohannesBierer]

I ofter can't find self intersections with the Check Geometry Tool, it is a bit unreliable especially with very small mistakes. I can offer several shapes with self intersections not found by Check Geometry Tool (10.4.1) - unfortunately I don't have pro.

[JoshuaBixby]

As I mentioned above, I put the coordinates into a projected spatial reference with lower tolerances, which appears to have done rounding and allowed Check Geometry to find the self-intersection.

The example geometry you provide raises several issues with Esri tools and underlying geometry model, so in that regard it is a good example, but that doesn't help you easily here since there are no easy workaround for the issues your example polygon raises.

[irfanlatif]

Thanks, everyone for your input.

As Joshua mention in ESRI environment there is no easy solution. So I have to go outside for help.

I build a small function using ogr to validate geometry. I have used buffer0 which is not a good option. If you have incorrect ring odder, you may end up with duplicate geometry. In my case it works fine as my base data is validated first with ESRI tools and then with ogr.

def ogr_Validate(fc):    
    """
    Used to validate input shapefile geometries with ogr
    INPUTS:
            fc(req) = path to fc            
            example. ogr_Validate(fc)
    IMP: Used buffer0 which in case of incorrect ring oder can produce duplicate geometries.    
    """

    inFc = ogr.Open(fc, update =1)
    inFc_lyr = inFc.GetLayer()
    
    for feature in inFc_lyr:
        geom = feature.GetGeometryRef()            
        if not geom.IsValid():
            print "Cleaning feature:      "+str(feature.GetField(lst_Fields(fc)[0]))        
            feature.SetGeometry(geom.Buffer(0))            
            inFc_lyr.SetFeature(feature) 
            assert feature.GetGeometryRef().IsValid() 
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Reference:

python - Invalid geometries made valid don't remain valid? - Geographic Information Systems Stack Ex... 

[KoryKramer]

The geometry team has reviewed this issue and wanted to convey the following:

The geometry in question is OGC Multipolygon type. If you look carefully it has three rings (with the two rings being in the second part).

While Esri polygon geometry type can represent both OGC Multipolygon and OGC Polygon types, it represents both as a collection of rings with exterior rings being clockwise and holes being counterclockwise.  When the Multipolygon in question is converted to Esri format it becomes a three ring polygon, and it is valid as far as Esri simple geometry  is concerned.

The OGC specification of simple features is more strict than Esri’s. To help with interoperability we’ve added the OGC option in the Check geometry and Repair Geometry tools.  When the OGC option is used, we check additional rules of the OGC spec and ensure that the polygon rings are sorted such that holes follow exterior rings.

What looks like the bowtie highlighted with blue color is actually two rings touching at a vertex.

Here is how to fix the original polygon to be valid for OGC spec:

MULTIPOLYGON(((18.580058 54.387989,18.580688 54.387949,18.581455 54.38745,18.58103 54.387236,18.581292 54.387046,18.581613 54.387193,18.581928 54.387025,18.581818 54.386618,18.581261 54.386702,18.580977 54.38657,18.581072 54.386234,18.580021 54.385724,18.579978 54.386042,18.580181 54.386148,18.579153 54.386818,18.579249 54.386861,18.578992 54.387036,18.578708 54.386886,18.578114 54.386992,18.57806 54.387864,18.578553 54.388089,18.580058 54.387989) move it here),((18.580058 54.387989,18.58009 54.388582,18.580315 54.388695,18.581319 54.388631,18.580058 54.387989),(18.580058 54.387989,18.579111 54.387517,18.579764 54.38739,18.580048 54.387528,18.580058 54.387989))) 

It only requires moving the last ring int the first POLYGON part.

[JoshuaBixby]

Kory Kramer‌, see my https://community.esri.com/message/894376-check-geometry-fails-in-shared-origin-edge-case thread that highlights a defect in Check Geometry that fails to identify invalid geometries in certain edge cases.