[postgis-users] st_union produces different result from st_memunion

[Martin Davis]

A further observation:  the data appears to contain some linework which is
derived from a raster dataset.  The error noted occurs amongst this
linework, and in fact there are quite a few other similar situations in
that linework.  This isn't surprising, since lines following a relatively
coarse raster grid might be exactly parallel in the source coordinate
system, but can be perturbed very slightly during reprojection (for
instance - there can be other causes as well).

On Mon, Jul 6, 2020 at 9:34 PM Martin Davis <mtnclimb at gmail.com> wrote:

> 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/ccd8f882/attachment.html>