[geos-devel] [FIXED] Buffering Multipolygons

[strk at refractions.net]

I've found and fixed the bug.
It was in LineSegment::reverse

Patch attached.
Affected versions: 2.0.0 to 3.0.0CVS

Might be worth setting up a branch for 2.1 so to come
out with a 2.1.2 ... what do you think ?

--strk;

On Thu, May 19, 2005 at 12:24:12PM +0200, strk at refractions.net wrote:
> Martin, inspecting this problem I found out a comment
> of you:
> 
>                 // <FIX> - handle negative depths
> 
> Actually, there's a negative depth in the 'non-working' case:
> 
>   BufferSubgraph::findResultEdges got 2 edges
>    dirEdge 0: depth:-1
>    dirEdge 1: depth:0
>   PolygonBuilder::buildMaximalEdgeRings got 2 dirEdges
>     dirEdge 0 inResult:0 isArea:1
>     dirEdge 1 inResult:0 isArea:1
>     returning 0 maxEdgeRings
> 
> While non negative depts are in the 'working' case:
> 
>   BufferSubgraph::findResultEdges got 2 edges
>    dirEdge 0: depth:0
>    dirEdge 1: depth:1
>      in result
>   PolygonBuilder::buildMaximalEdgeRings got 2 dirEdges
>     dirEdge 0 inResult:0 isArea:1
>     dirEdge 1 inResult:1 isArea:1
>     returning 1 maxEdgeRings
> 
> I checked JTS and the notice is still there (your comment).
> Anyway Dave reports it is working with JTS. Do you have
> any hint on how to proceed ?
> 
> --strk;
> 
> 
> 
> On Thu, May 19, 2005 at 08:48:13AM +0200, strk at refractions.net wrote:
> > Found out that geos-2.0.0 already has this bug.
> > 
> > It seems related to vertex order. If you swap vertex order
> > of second shell result is correct:
> > 
> >   <a>
> > MULTIPOLYGON (((10 10, 10 20, 20 20, 20 15, 10 10)),
> > 	((60 60, 80 60, 70 7, 60 60)))
> >   </a>
> > 
> > Martin, where should vertex order be enforced ?
> > 
> > --strk;
> > 
> > 
> > On Wed, May 18, 2005 at 07:52:09PM +0200, strk at refractions.net wrote:
> > > On Wed, May 18, 2005 at 09:08:23AM -0400, dblasby at openplans.org wrote:
> > > > buffering this in JUMP (using JTS), works fine.
> > > > 
> > > > -->
> > > > MULTIPOLYGON (((10 10, 10 20, 20 20, 20 15, 10 10)),
> > > >   ((60 60, 70 7, 80 60, 60 60)))
> > > > 
> > > > strk; your result is not correct.  You've lost the 1st polygon!
> > > 
> > > You're right! I've verified geos-1.0.0 not having this problem.
> > > I'll check out 2.0.0 and up and see what broke this.
> > > I'll add a test in testLeaksBig.xml for this as well.
> > > Following is the XML test (parametrized buffer argument will only work
> > > with GEOS CVS, other versions will use 10 as argument instead of arg3):
> > > 
> > > <run>
> > >   <precisionModel type="FLOATING"/>
> > > 
> > > 
> > > <case>
> > >   <desc>Multipolygon buffering</desc>
> > >   <a>MULTIPOLYGON (((10 10, 10 20, 20 20, 20 15, 10 10)), ((60 60, 70 7, 80 60, 60 60)))</a>
> > > <test>
> > >   <op name="buffer" arg1="a" arg3="0">
> > >   	MULTIPOLYGON (((10 10, 10 20, 20 20, 20 15, 10 10)), ((60 60, 70 7, 80 60, 60 60)))
> > >   </op>
> > > </test>
> > > </case>
> > > 
> > > 
> > > </run>
> > > 
> > > 
> > > --strk;
> > > _______________________________________________
> > > geos-devel mailing list
> > > geos-devel at geos.refractions.net
> > > http://geos.refractions.net/mailman/listinfo/geos-devel
> > _______________________________________________
> > geos-devel mailing list
> > geos-devel at geos.refractions.net
> > http://geos.refractions.net/mailman/listinfo/geos-devel
> _______________________________________________
> geos-devel mailing list
> geos-devel at geos.refractions.net
> http://geos.refractions.net/mailman/listinfo/geos-devel