Thank you for the prompt feedback. As you suggested I tried using ST_SnapToGrid and that worked very well even with a very fine grid - st_snaptogrid(geometry,0.000000000001). However when it came to a collection of lines more useful for real work (13540 records compared with 6 in the minimal dataset) I found that snapping even to a grid so coarse as to render the data useless - st_snaptogrid(geometry,0.01) - still produced an incorrect result.
Here is the dump of my larger dataset: https://anonfiles.com/rdYcG1Edo2/dbca_dump_116_35_117_34_sql I'll have a go myself with OverlayNG. And I will file a PostGIS issue depending on the conclusions from this discussion. Cheers, Jonathan On 7/7/20 12:41 pm, Martin Davis wrote:
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] <mailto:[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] <mailto:[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] <mailto:[email protected]> https://lists.osgeo.org/mailman/listinfo/postgis-users _______________________________________________ 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
