Intersection of certain GeometryCollections segfaults

Expected behavior and actual behavior.

intersection() method segfaults when intersecting a Polygon with some GeometryCollection. Converting the collection into a MultiPolygon fixes the problem.

I tried coming up with arbitrary GeometryCollections but I couldn’t reproduce the error except for the example below.

Steps to reproduce the problem.

from shapely.geometry import shape
from shapely.ops import unary_union


polygon = shape({
    "type": "Polygon",
    "coordinates": [[
        [132.55004882812503, 34.2288353852272],
        [132.55004882812503, 34.22997081127308],
        [132.55142211914062, 34.22997081127308],
        [132.55142211914062, 34.2288353852272],
        [132.55004882812503, 34.2288353852272]
    ]]
})

collection = shape({
    "type": "GeometryCollection",
    "geometries": [{
        "type": "MultiPolygon",
        "coordinates": [
            [[
                [132.55004882812503, 34.22993173063148],
                [132.55004882812503, 34.22997081127308],
                [132.5500874053658, 34.22997081127308],
                [132.55004882812503, 34.22993173063148]
            ]],
            [[
                [132.5501380995388, 34.22997081127308],
                [132.55180084417634, 34.22997081127308],
                [132.55180084417634, 34.228694170127646],
                [132.5501380995388, 34.22997081127308]
            ]]
        ]
    }]
})

# Intersecting this particular collection fails
polygon.intersection(collection)

# Converting the collection into a multipolygon circumvents the segfault and
# works as expected
multipolygon = unary_union(collection)
polygon.intersection(multipolygon)

Operating system

Reproduced on MacOS 10.15 Catalina and an up-to-date Manjaro Linux installation.

Shapely version and provenance

Fails on both 1.6.4.post2 and 1.7.0 installed via pip in a clean virtualenv.

Thanks for any information on the problem or a fix.

[jorisvandenbossche]

@dr-jts thanks a lot for that detailed answer!

I’m pretty sure that inputs with overlapping polygons will always raise error, rather than crashing. The downside to just reporting that error back to the user is that it is pretty low-level, and doesn’t inform him of the real problem (overlapping polygon inputs).

In that case, I think I would personally prefer to just pass inputs to GEOS. It is certainly true that the error from GEOS like “side location conflict at 1 2” is not at all informative (side question: is this something that could be improved in GEOS? Or is it too much down into the operation to have useful context to report about the error?). But checking in advance if polygons in collections are overlapping also doesn’t sound that an attractive option. Alteratively, we could still catch the error from GEOS and reraise it with some additional explanation about what might be causing the issue.

[dr-jts]

@dr-jts is your comment still correct for the new OverlayNG in GEOS 3.9.0 as well? (which was released after your comment, although already in active development / in GEOS master at that time). I suppose yes?

Yes, the comment about “strictly speaking GeometryCollections are not handled” still applies to OverlayNG.

OverlayNG will process some GeometryCollections, but with the following limitations:

• heterogeneous (mixed) collections are not supported (they throw an IllegalArgumentException)
• collections containing overlapping polygons will probably throw an error (as you note below)
• the semantics for GeometryCollections hasn’t been formally defined. At the moment they just have the same behaviour as typed collections, but that might change in the future to something slightly different

I am personally a bit wary of generally raising an exception for all GeometryCollection inputs. I think that might give lots of errors also in cases where the result was actually fine (eg for geopandas users with arrays of geometries, you might have introduced some geometry collections with another operation). If we go this route, we should at least first warn about it I think.

Yes, it should be safe to allow all but collections with overlapping polygons. Not guaranteed that semantics won’t change at some point in the future, though.

So if GEOS generally raises errors (instead of crashing) for cases it doesn’t support (but does it do this generally?), this might already be good enough without specific checks needed in Shapely?

I’m pretty sure that inputs with overlapping polygons will always raise error, rather than crashing. The downside to just reporting that error back to the user is that it is pretty low-level, and doesn’t inform him of the real problem (overlapping polygon inputs). Also, in the past the same error could be caused by a robustness issue, which made it even harder for the user to determine what was wrong. However, that situation has (hopefully) been eliminated by OverlayNG, so it should be safe to assume that an error indicates overlapping polygon input.