a strange bug of polygon intersection

[chunxinxie]

I encountered a very strange bug when using github.com/peterstace/simplefeatures/geom :
there are two polygons: the small polygon is inside the the large polygon,
but the result of their intersection (Geometry.Intersection) is the large one.

Can you take a look if there is a bug? Thanks!

small one's geojson:
{
"coordinates": [
[
[
112.409282,
34.638641
],
[
112.409268,
34.638646
],
[
112.40926,
34.638642
],
[
112.409252,
34.638642
],
[
112.408256,
34.63827
],
[
112.408249,
34.638271
],
[
112.408247,
34.638254
],
[
112.408246,
34.638259
],
[
112.408248,
34.638249
],
[
112.408352,
34.638021
],
[
112.408362,
34.638014
],
[
112.408362,
34.638011
],
[
112.408375,
34.638008
],
[
112.408376,
34.63801
],
[
112.409396,
34.638386
],
[
112.409402,
34.638393
],
[
112.409411,
34.638395
],
[
112.409404,
34.638407
],
[
112.409288,
34.638638
],
[
112.409282,
34.638641
]
]
],
"type": "Polygon"
}

the large one's geojson:
{
"coordinates": [
[
[
112.3681640625,
34.6728515625
],
[
112.3681640625,
34.62890625
],
[
112.412109375,
34.62890625
],
[
112.412109375,
34.6728515625
],
[
112.3681640625,
34.6728515625
]
]
],
"type": "Polygon"
}

[chunxinxie]

the version is v0.50.0

[peterstace]

Hi @chunxinxie, thank you for your report.

I've been able to reproduce the problem (see d1ff6cc).

I will look into finding the precise cause, although I suspect it's related to the hairline sliver in one of the input geometries shown below. While both inputs are reported as valid by simplefeatures, slithers like this can cause numerical stability issues that can cause incorrect results.

To work around the problem, I would suggest one of these approaches:

• Clean up the input data to remove the hairline slither.
• Use the github.com/peterstace/simplefeatures/geos package (rather than the .../geom package). This package utilises the GEOS C++ library for geometry operations, and has fewer of these sorts of errors (at the expense of introducing a CGO dependency).

[chunxinxie]

Hi @chunxinxie, thank you for your report.

I've been able to reproduce the problem (see d1ff6cc).

I will look into finding the precise cause, although I suspect it's related to the hairline sliver in one of the input geometries shown below. While both inputs are reported as valid by simplefeatures, slithers like this can cause numerical stability issues that can cause incorrect results.

To work around the problem, I would suggest one of these approaches:

• Clean up the input data to remove the hairline slither.
• Use the github.com/peterstace/simplefeatures/geos package (rather than the .../geom package). This package utilises the GEOS C++ library for geometry operations, and has fewer of these sorts of errors (at the expense of introducing a CGO dependency).

Thanks for your detailed investigation!

I'll process the hairline slither cases in my codes. Using /geom package is just for getting rid of cgo dependency, so, I'll continue to use /geom :-)

btw, Is there any plan to provide approaches for such cases? like, reporting such shape as invalid, or, providing some "shape cleaning" methods?

[peterstace]

btw, Is there any plan to provide approaches for such cases? like, reporting such shape as invalid, or, providing some "shape cleaning" methods?

One reasonable shape cleaning method to remove slithers is to buffer the geometry inwards by a small amount, and then buffer outwards by that same amount. The first buffer removes the slithers entirely, and the second buffer restores the shape back to its original size (without the slithers).

In order to do that, you need a Buffer operation. I'm tracking the Go implementation of Buffer here: #349 (it's planned, but I'm not actively working on it right now).

[chunxinxie]

btw, Is there any plan to provide approaches for such cases? like, reporting such shape as invalid, or, providing some "shape cleaning" methods?

One reasonable shape cleaning method to remove slithers is to buffer the geometry inwards by a small amount, and then buffer outwards by that same amount. The first buffer removes the slithers entirely, and the second buffer restores the shape back to its original size (without the slithers).

In order to do that, you need a Buffer operation. I'm tracking the Go implementation of Buffer here: #349 (it's planned, but I'm not actively working on it right now).

Thanks! Buffer op can work, but it might be a bit expensive... I'll scan the boundary points and use some checking strategies.

Buffer is indeed a useful general geom op, I still use it by geos in my project. looking forward to your implementation :-)