[postgis-users] st_union produces different result from st_memunion

[Martin Davis]

This sounds very similar to this recent ticket:

https://trac.osgeo.org/postgis/ticket/4711

You can review the ticket for details of what the problem is.  ST_Union is
encountering some linework which causes a robustness failure.  This
triggers a heuristic snap-to-a-grid to try and handle it.  The heuristic is
overly aggressive, and as a result loses most of the precision in the input
geometries.

The reason that one area works and another doesn't is that the geometry in
the first area does not contain a line arrangement which causes a
robustness issue, but the second does.

The usual cause of robustness problems in overlay is nearly coincident
linework, and that is the case here.  The data contains the following two
nearly coincident lines (and possibly others as well):

LINESTRING (117.00230437069528 -34.90245574160274, 117.00230435800071
-34.902001026632455)
LINESTRING (117.00230437069528 -34.902455741602736, 117.00230435800043
-34.902001016643766)

I'm not sure why ST_MemUnion works in this case - probably due to a
slightly different implementation of heuristics.

You might try using ST_SnapToGrid on the linework - that sometimes helps,
by removing excess precision and also by perturbing lines enough to avoid
the problem.

The forthcoming OverlayNG should provide a fix for this (see issue for more
detail).  I've confirmed that OverlayNG can handle the linework in the
sample data.  If you are able to file a PostGIS issue for this that will
help us track the problem.


On Mon, Jul 6, 2020 at 8:47 PM Jonathan Schultz <jonathan at schultz.la> wrote:

> Following my earlier question
> https://lists.osgeo.org/pipermail/postgis-users/2020-June/044253.html
> that didn't get any responses, I have isolated my problem down to a minimal
> case consisting of six LineStrings, where st_union produces an obviously
> incorrect result while st_memunion produces an apparently correct result.
>
> What appears to happen is that st_union produces a result where the
> vertices have been snapped to a grid of distance approximately 1km.
>
> The table dump is here:
> https://anonfiles.com/1fad81Edo2/bad_dump_minimal_2_minimal_sql To
> reproduce the problem all you need is a simply query:
>
> > SELECT st_union(geometry)
> >   FROM bad_dump_minimal_2_minimal
>
> Can anyone suggest what might be happening or what I could do to
> investigate further?
>
> Thanks,
>
> Jonathan
> _______________________________________________
> postgis-users mailing list
> postgis-users at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/postgis-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20200706/901471bd/attachment.html>