Ah, my bad - the dependency on FunctionUtil should not be in the main jts module. I'll fix that now. Thanks for finding this!
On Wed, May 27, 2015 at 1:16 PM, Jan Tosovsky <[email protected]> wrote: > It seems to be a quite substantial rewrite, thanks for it! > > I’ve tried to build it from trunk (ant executed in the root folder), but I > am getting following errors: > > > > [javac] > D:\Java\components\jts-trunk\jts\java\src\com\vividsolutions\jts\nod > > ing\SegmentStringUtil.java:96: error: cannot find symbol > > [javac] LineString line = > FunctionsUtil.getFactoryOrDefault(null).crea > > teLineString(ss.getCoordinates()); > > [javac] ^ > > [javac] symbol: variable FunctionsUtil > > [javac] location: class SegmentStringUtil > > [javac] > D:\Java\components\jts-trunk\jts\java\src\com\vividsolutions\jts\nod > > ing\SegmentStringUtil.java:100: error: cannot find symbol > > [javac] return > FunctionsUtil.getFactoryOrDefault(null).createMultiLineSt > > ring(lines); > > [javac] ^ > > [javac] symbol: variable FunctionsUtil > > [javac] location: class SegmentStringUtil > > > > Does it compile for you? Or have I overlooked something? This is my first > attempt to build this project... > > > > Thanks, Jan > > > > From: Martin Davis [mailto:[email protected]] > Sent: Wednesday, May 27, 2015 6:20 PM > To: Jan Tosovsky > Cc: [email protected] > Subject: Re: [Jts-topo-suite-user] Polygonizer issue > > > > Here's the link to the rev: > https://sourceforge.net/p/jts-topo-suite/code/974/tree/ > > > > On Tue, May 26, 2015 at 4:32 PM, Martin Davis <[email protected]> wrote: > > Further to this issue: I"ve enhanced the Polygonizer to be able to extract > only polygons which form a valid polygonal geometry. The algorithm can > handle nested polygons as described below. > > > > It's in SVN at r974 > > > > On Wed, May 6, 2015 at 9:19 AM, Martin Davis <[email protected]> wrote: > > Actually I see now that Daniel Baston's algorithm is a bit smarter, since > it > can handle nested polygons as well. I think the algorithm I posted can be > extended to have this behaviour as well - it just needs to classify > polygons > as holes or non-holes in the same kind of way, iterating from the outside > in. > > > > On Wed, May 6, 2015 at 9:11 AM, Martin Davis <[email protected]> wrote: > > Yes, it's not surprising that code that relies heavily on intersection() > and > intersects() is inefficient - because those methods are so general-purpose, > they are expensive to execute. > > > > Here's one idea for a faster algorithm (caveat - I have not implemented > this, and there may be corner cases): > > > > - Extract all the line segments from all holes in the set of polygons > output > from Polygonizer, normalize them, and add them to a Set holeSeg > > - For each polygon, test if any segment from its shell lies in the holeSeg > Set. If it does, discard it. Otherwise, that polygon is an "outer" > polygon. > > > > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Jts-topo-suite-user mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/jts-topo-suite-user > >
------------------------------------------------------------------------------
_______________________________________________ Jts-topo-suite-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jts-topo-suite-user
