Reading an invalid geometry from an ESRI shapefile displays the geometry as valid (using gdal-master channel).

[KriWay-LV]

What is the bug?

We have an invalid geometry in a shapefile, and when we read that shapefile using the GDAL version from the GDAL-master channel, that geometry is marked as valid.

Steps to reproduce the issue

test_isvalid.py

Steps in script:

• Demonstrate that the WKT is not valid.
• Create a GeoPackage using OGR and show that the geometry is still not valid.
• Create a shapefile using OGR and show that the geometry is now valid.

Versions and provenance

We tested against the gdal-master channel.

gdal 3.12.99 py313h6de05c7_2112 gdal-master
libgdal-core 3.12.99 h977623c_2112 gdal-master
GDAL 3.13.0beta1, released 2026/04/20

Operating system: Windows 11

Additional context

This bug was observed during a test of geofileops against GDAL-master.

[jratike80]

That geometry is valid for ESRI. The ESRI way to make a hole that is touching the boundary is to make a loop to the boundary line. For OGC that is an error and hole must be a distingt inner ring. PostGIS has an ESRI flag for this purpose. This test is with the ESRI flag.

select st_isvalidreason(
	'MultiPolygon (((87558.41007209420786239 188918.48513316549360752, 87558.9678320944076404 188918.19700516480952501, 87558.75944809467182495 188917.75367716606706381, 87548.63451600799453445 188923.0363450045697391, 87561.25152940554835368 188924.34495891860569827, 87559.12674409002647735 188917.89313316438347101, 87558.9678320944076404 188918.19700516480952501, 87558.73365609199390747 188918.6448771683499217, 87558.41007209420786239 188918.48513316549360752),(87554.96405608800705522 188920.0027011688798666, 87559.67816809416399337 188920.66855716705322266, 87556.31522409469471313 188923.16775717120617628, 87554.96405608800705522 188920.0027011688798666)))',1)

valid geometry

But with the OGC rules

select st_isvalidreason(
	'MultiPolygon (((87558.41007209420786239 188918.48513316549360752, 87558.9678320944076404 188918.19700516480952501, 87558.75944809467182495 188917.75367716606706381, 87548.63451600799453445 188923.0363450045697391, 87561.25152940554835368 188924.34495891860569827, 87559.12674409002647735 188917.89313316438347101, 87558.9678320944076404 188918.19700516480952501, 87558.73365609199390747 188918.6448771683499217, 87558.41007209420786239 188918.48513316549360752),(87554.96405608800705522 188920.0027011688798666, 87559.67816809416399337 188920.66855716705322266, 87556.31522409469471313 188923.16775717120617628, 87554.96405608800705522 188920.0027011688798666)))',0)

Ring Self-intersection

[rouault]

That geometry is valid for ESRI.

exactly. The change was done in e2d4cfe ([EDIT]) , and is specifically located at

gdal/ogr/ogrgeometryfactory.cpp

Line 1903 in 1e9de45

// This method may be called with ESRI geometries whose validity

It might arguably be a bit fragile: we detect that 2 non consecutive node are found in the same ring, and then call MakeValid() to fix them, to be able to use afterwars GEOS topological operations (Within etc). If the input ring was indeed invalid beyond a simple loop it would be repaired anyway, but I don't think that GEOS offers a way to detect a ring whose only OGC invalidity is to form a loop ? (maybe @dbaston can confirm/infirm that)

[jratike80]

Another variant is that for ESRI this polygon in valid, but for OGC rules it must be expressed as a multipolygon with two parts.

POLYGON (( 363 239, 408 278, 355 320, 452 321, 408 278, 451 236, 363 239 ))

Notice that this is not a typical butterfly polygon, the winding order stays clockwise as it must be in shapefiles.

" 2 non consecutive node are found in the same ring" detection works for this too.

[jratike80]

but I don't think that GEOS offers a way to detect a ring whose only OGC invalidity is to form a loop

There seems to be setSelfTouchingRingFormingHoleValid() but by the description it does not handle the hourglass polygons. Otherwise I think it would be possible to conclude "invalid without the flag, valid with the flag -> that's valid but ESRI". But would it be reasonable, I doubt.

https://libgeos.org/doxygen/classgeos_1_1operation_1_1valid_1_1IsValidOp.html#ae2997fc9c969f19517184377df9249de

[dbaston]

I don't think that GEOS offers a way to detect a ring whose only OGC invalidity is to form a loop ?

You can use GEOSisValidDetail with the flag GEOSVALID_ALLOW_SELFTOUCHING_RING_FORMING_HOLE