Fixed-precision overlay methods fail if inputs are mixed dimensions

[Brendan Ward]

Using the fixed-precision overlay methods (GEOSIntersectionPrec, GEOSDifferencePrec, etc) via the C API results in an error: "IllegalArgumentException: Overlay input is mixed-dimension"

Example WKT (just overlayed against itself): "GEOMETRYCOLLECTION (POINT (51 -1), LINESTRING (52 -1, 49 2))"

This does not raise errors on the non fixed-precision overlay methods.

Detected via tests in pygeos (​https://github.com/pygeos/pygeos/pull/276).

I think this was mentioned in a related issue on the mailing list: ​http://osgeo-org.1560.x6.nabble.com/3-9-0beta1-GEOSwift-td5451132.html

I think this is the related JTS issue: ​https://github.com/locationtech/jts/pull/648

[mdavis]

This is expected behaviour. As the error states, overlay does not handle arguments of mixed dimension. The input on this ticket obviously fails this criteria.

This semantic is not new with OverlayNG - it has always been present in GEOS overlay.

[Brendan Ward]

Perhaps there is additional validation in the fixed-precision methods?

GEOSIntersection returns the input geometry when that is intersected with itself, without raising an error.

I see that the OverlayNG methods specifically check for this case: ​https://github.com/libgeos/geos/blob/3.9/src/operation/overlayng/EdgeNodingBuilder.cpp#L194-L196

I wasn't able to easily find the counterpart for geometry collections in the original overlay implementation.

Not arguing that this should work for mixed dimensions, only that the behavior is different between the fixed and original operations, in case it identifies a potential bug. In this case, it seems like OverlayNG is a bit more strict, which is probably a good thing.

[dbaston]

Superseded by ​https://github.com/libgeos/geos/issues/797