Spatial indexes loose invalid multipolygons with segment in common.

[nonolingenieur]

Observed in QGIS master (2.9).

To reproduce:

• Draw a polygon.
• Using advanced digitizing split parts tool, split the polygon in two parts.
• Save the modifications.
• Select the polygon using the two parts.

=> One part select the feature, the other do not.

After introspection, the feature isn't returned by the iterator using the spatial index when the selection bbox intersect the second part of the invalid multipolygon. This iterator should use the OGR API.

Related ticket on QGIS tracker: ​https://hub.qgis.org/issues/12799

[nonolingenieur]

Example shapefile with an invalid multipolygon with one segment in common

[Even Rouault]

One issue I saw is that the .qix file shouldn't be there since it points to records that have been deleted. Normally OGR deletes the .qix when features are deleted with it, so I suspect that part of the processing didn't involve OGR. When selecting an no longer existing shape referenced by the .qix, this caused a problem preventing later reads to succeed.

Fixed by trunk r29234, branches/1.11 r29235 "Shape: SHPReadOGRFeature() should free the passed psShape when not NULL and if the DBF record is deleted, so as to avoid later reads to faild (triggered by #5974, but not fixing it)"

For the core issue, well, it is GEOS that declares there's no intersection when the multipolygon is invalid. Considering if we should split the multipolygon before doing the intersection test...

[Even Rouault]

Ah, I stand corrected. The shapefile driver reads the geometry as a POLYGON with an exterior and interior ring, not a MULTIPOLYGON, so my above remark does not yet apply. Now the issue is to determine if we could build a MULTIPOLYGON from this geometry...

[Even Rouault]

Closer analysis shows that one of the rings has clockwise orientation, while the other one has conter-clockwise orientation, so in shapefile convention, this means that one is the inner ring of the other one (clockwise = outer ring, counter clocksie = inner ring). So the shape, as in the .shp, is not built as a multipolygon. That's the blocking issue.

I'd note that the export code of the shapefile driver in its topological analysis to properly turn rings into clockwise or counter-clockwise will correct it (if you do: ogr2ogr out.shp polygon.shp). So this shape hasn't been written with OGR. With that corrected shapefile, the spatial intersection works correctly (even if GEOS still protest about self-intersection when running IsValidReason())

Closing this ticket as not a OGR bug. The 2 issues are from a non-OGR writer that 1) leaves an invalid .qix file 2) generates an invalid shapefile with wrong winding order.