[geos-devel] Noding linework
Sandro Santilli
strk at keybit.net
Fri Jul 15 09:55:43 EDT 2011
On Thu, Jul 14, 2011 at 08:17:55PM -0700, Martin Davis wrote:
> Yes, union() is supposed to fully node linework.
>
> This case works fine in JTS 1.11 (and JTS 1.12) - i.e. running the
> equivalent of polygonize( union( boundary(A), B). The output from
> the union checks out as being fully noded, and the polygonize
> produces 2 valid polygons.
>
> So possibly this is one of those numerical issues which shows up in
> GEOS in native code, but not in JTS in Java? This maybe one of
> those cases where GEOS and JTS need to be traced through in parallel
> (which seems really painful, but I think you've done this in the
> past, right?)
Found.
Contrary to JTS, which engages SnapRounding on first robustness failure,
GEOS first tries with a pure CommonBitsRemover approach:
Trying with original input.
Original exception: TopologyException: found non-noded intersection between LINESTRING (1.72293e+06 4.78835e+06, 1.72293e+06 4.78835e+06) and LINESTRING (1.72293e+06 4.78835e+06, 1.72293e+06 4.78834e+06) at 1.72293e+06 4.78835e+06
Trying with Common Bits Remover (CBR)
I've seen in the past already that re-adding previously removed common
bits may introduce invalidities (we discussed this in another occasion).
That's because some of the lowermost bits fall off possibly moving the
vertices to fall on a given grid. Evidentily this was the case in GEOS,
where the output from Union against the shifted geometries was fully noded
but became non-noded when re-adding common bits.
Indeed going SnapRounding directly gives a fully noded output !
But it gives failures (found non-noded intersection) in a
couple of testcase:
bug360.xml (http://trac.osgeo.org/geos/ticket/360) [JTS works]
bug392.xml (http://trac.osgeo.org/geos/ticket/392) [JTS throws an exception!]
--strk;
() Free GIS & Flash consultant/developer
/\ http://strk.keybit.net/services.html
More information about the geos-devel
mailing list