panic with Union

[akhenakh]

panic with Union

[wiki0831]

--alternative temp fix--
You can try reducing floating point precision to 6 decimal place (which is about 111mm), this will return a valid output and preserve the overall topology.

reference implementation:

func ReducePrecision(g geom.Geometry, decimalPlace int) geom.Geometry {
	processPoint := func(xy geom.XY) geom.XY {
		ratio := math.Pow(10, float64(decimalPlace))
		x := math.Round(xy.X*ratio) / ratio
		y := math.Round(xy.Y*ratio) / ratio
		return geom.XY{X: x, Y: y}
	}
	return g.TransformXY(processPoint)
}

https://go.dev/play/p/nckAWTeE8gR

[peterstace]

Thank you for the detailed bug report, I should get some time to take a look at this soon.

[akhenakh]

Having CGO is not too much of a problem, like on a CI it's okay, but the burden to maintain it for every developers environments, Mac windows ... is a bigger task, having the default build flag using the native not optimized Go would be the best option and a geos build tag for the CGO one.

But I remember you had a different API between geos and geom, which would make this difficult to implement it like that.

Thanks again for all the help, we are using your lib and it performs really well, most of the time using the native Go anyway.

[akhenakh]

FYI the resulting polygon is probably invalid.

They visually look contiguous, but they are not, and they're actually only touching in 2 points.

[akhenakh]

I've tested your fix branch on the same dataset, with success. Thank you.

[peterstace]

Thanks for testing! FYI I've created a new tag v0.42.0 that contains the panic fix.

I haven't worked out a fix for the root cause of the issue -- that's something I still intend to look into.

In the meantime, you may wish to look into using the Union wrapper from the GEOS C library. It handles those geometry without giving an error.

[peterstace]

A fix for the root cause has been added in v0.46.0.

[akhenakh]

Thanks for the heads up, we switched to geos. Do you recommend moving back to the Go implementation?

[peterstace]

The main reasons you may wish to switch back to the Go implementation (and avoid the GEOS dependency) would be if you:

• You wish to avoid the dependency on the GEOS C++ library (and CGO in general). The GEOS dependency can potentially be annoying to manage (depending on your setup). E.g. getting all developers on your team to install the same version locally. It can be difficult to get a recent version of GEOS if you're stuck on an older base image (assuming you're using docker for deployments).
• CGO in general degrades much of the Go experience. Builds become slower and more complicated, cross-compilation becomes more difficult, some tools stop working (e.g. profiling).

The main reason to stay with the geos package:

• It's faster than the Go implementation.
• In my experience, the latest version (v3.11 and onwards) is very stable with regard to the correctness of results (earlier versions have a lot of miscellaneous problems). It's used much more widely than the Go implementation in simplefeatures, so is better battle-hardened.

If the drawbacks of the geos package and the CGO/GEOS dependency are not too bad for you, I'd recommend staying with geos.