[geos-devel] [FIXED] Buffering Multipolygons

strk at refractions.net strk at refractions.net
Mon May 23 11:25:18 EDT 2005


Ok, branch-2-1 is tagged in CVS and the patch has already
been back-ported. I'll take a look at the head ChangeLog
to find other big fixes if any.

--strk;

On Mon, May 23, 2005 at 10:22:19AM -0500, Steve Lime wrote:
> Excellent, thanks for pursuing! In my opinion that was a big fix and
> would warrant a 2.1.2 if 3.0 is still a ways out.
> 
> Steve
> 
> >>> strk at refractions.net 5/23/2005 10:18:38 AM >>>
> 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 
> _______________________________________________
> geos-devel mailing list
> geos-devel at geos.refractions.net 
> http://geos.refractions.net/mailman/listinfo/geos-devel



More information about the geos-devel mailing list