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 <[email protected]> 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 <[email protected]> > 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 >> [email protected] >> https://lists.osgeo.org/mailman/listinfo/postgis-users > >
_______________________________________________ postgis-users mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/postgis-users
