ah.. anyway.. thanx Larry! Larry Becker schrieb: > Hi Martin, > > The union operation is implemented by buffering the union of the > input, rather than the union of the input buffered, if you see the > distinction. I was hoping JTS had already optimized this, but from > what you are saying, I would guess not. > > Larry > > On 8/31/07, Martin Davis <[EMAIL PROTECTED]> wrote: >> Cool... >> >> I think that one way around the "slow union" problem is to develop a >> "Cascading Union" function. This will build up a union of multiple >> geometries by forming them into a tree, and recursively unioning the >> branches of the tree from the leaves to the root. In theory this >> should provide a fairly optimal balance between performance and memory use. >> >> A nice way to form the tree would be to add the input geometries to a >> JTS Quadtree or STRtree and then traverse the tree in depth-first >> order. Unfortunately currently the implementations don't support the >> ability to traverse the tree in any order - this wouldn't be too hard to >> add, though. >> >> Thoughts? Anyone keen on trying this out? >> >> Martin >> >> >> >> Larry Becker wrote: >>> I have committed the improved buffer plugin. Three sample screens are >>> attached in english, french, and german. It now supports buffering >>> the selection. It provides a convenience union option. The sidebar >>> picture now previews the current options. It copies attributes by >>> default, even from selections on multiple layers, but this can be >>> turned off. It supports setting the number of segments in a quarter >>> circle. >>> >>> Be careful with the union operation. With large selections, it can >>> take a long time. For instance using Uwe's GeoCity project, I tried >>> to buffer everything by 1000 meters. Without union it completed in >>> about 20 seconds, and with union I finally killed it after 5 minutes. >>> >>> regards, >>> Larry Becker >>> >>> >>> ------------------------------------------------------------------------ >>> >>> >>> ------------------------------------------------------------------------ >>> >>> >>> ------------------------------------------------------------------------ >>> >>> ------------------------------------------------------------------------ >>> >>> ------------------------------------------------------------------------- >>> This SF.net email is sponsored by: Splunk Inc. >>> Still grepping through log files to find problems? Stop. >>> Now Search log events and configuration files using AJAX and a browser. >>> Download your FREE copy of Splunk now >> http://get.splunk.com/ >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Jump-pilot-devel mailing list >>> Jump-pilot-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >>> >> -- >> Martin Davis >> Senior Technical Architect >> Refractions Research, Inc. >> (250) 383-3022 >> >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by: Splunk Inc. >> Still grepping through log files to find problems? Stop. >> Now Search log events and configuration files using AJAX and a browser. >> Download your FREE copy of Splunk now >> http://get.splunk.com/ >> _______________________________________________ >> Jump-pilot-devel mailing list >> Jump-pilot-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >> > >
------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
