On Wed, Apr 17, 2019 at 08:01:43AM -0700, Martin Davis wrote: > (Kudos to you for finding the failing test case. Was that just by chance, > or would you be able to give the new potential fix a good workout?)
I think it was reported by a user of PostGIS Topology, where unions is used heavily. I probably just reduced the testcase. No time to stress new implementation out (but build PostGIS Topology, it's so easy to get exceptions ! :) > But... I think there is a slim possibility that: > (a) The envelope does not change > (b) The union moves a line segment slightly (due to snapping or simply by > having a new node introduced) > (c) There is a geometry which lies just outside the overlap extent which is > close enough to the changed segment that it is now intersected By "is now intersected" in (c) you mean it is moved by snapping/precision-reducing heuristics in further unioning ? If that's the case, can't we check envelope intersection again afterwards ? > It might be possible to come up with a synthetic test case to demonstrate > this (perhaps using a fixed precision mode, which tends to highlight these > kinds of issues). It'd be great to try hard to break it :) > One further test would be to compare all the line segments of the union > which lie outside the overlap extent. If they have not changed then there > should be no risk of an intersection with the other outside polygons. I > think this should be significantly faster than doing the full union. I'l > try working that up and see what the impact is. Thank you, it's great to see you full speed on GEOS ! --strk; _______________________________________________ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
