<div dir="ltr">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).</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jul 6, 2020 at 9:34 PM Martin Davis <<a href="mailto:mtnclimb@gmail.com">mtnclimb@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">This sounds very similar to this recent ticket:<div><br></div><div><a href="https://trac.osgeo.org/postgis/ticket/4711" target="_blank">https://trac.osgeo.org/postgis/ticket/4711</a><br></div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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):</div><div><br></div><div>LINESTRING (117.00230437069528 -34.90245574160274, 117.00230435800071 -34.902001026632455)<br></div><div>LINESTRING (117.00230437069528 -34.902455741602736, 117.00230435800043 -34.902001016643766)<br></div><div><br></div><div>I'm not sure why ST_MemUnion works in this case - probably due to a slightly different implementation of heuristics.<br></div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jul 6, 2020 at 8:47 PM Jonathan Schultz <<a href="mailto:jonathan@schultz.la" target="_blank">jonathan@schultz.la</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Following my earlier question <a href="https://lists.osgeo.org/pipermail/postgis-users/2020-June/044253.html" rel="noreferrer" target="_blank">https://lists.osgeo.org/pipermail/postgis-users/2020-June/044253.html</a> 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.<br>
<br>
What appears to happen is that st_union produces a result where the vertices have been snapped to a grid of distance approximately 1km.<br>
<br>
The table dump is here: <a href="https://anonfiles.com/1fad81Edo2/bad_dump_minimal_2_minimal_sql" rel="noreferrer" target="_blank">https://anonfiles.com/1fad81Edo2/bad_dump_minimal_2_minimal_sql</a> To reproduce the problem all you need is a simply query:<br>
<br>
> SELECT st_union(geometry)<br>
> FROM bad_dump_minimal_2_minimal<br>
<br>
Can anyone suggest what might be happening or what I could do to investigate further?<br>
<br>
Thanks,<br>
<br>
Jonathan<br>
_______________________________________________<br>
postgis-users mailing list<br>
<a href="mailto:postgis-users@lists.osgeo.org" target="_blank">postgis-users@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/postgis-users" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/postgis-users</a></blockquote></div>
</blockquote></div>