This sounds like a great solution Larry, but I was wondering if you might be able to confirm why selection requires more memory than a fence.
Is it because when you use "selection" a bunch of Java collections are created, whereas when you use a fence, you are just creating a geometry? Is it because with the fence no data structures for the features within the fence are created until you actually want to do something? The only problem I see with using a fence is that it wouldn't allow complex selections. (For example, if I use a fence all the features are the fence are in the "quasi-selection".I can't go in an remove some items from the quasi-selection. Does this make sense?) I worked with some of the selection code recently, and it seemed very complex to me. There were so many collections being used in the code I had to write the purpose of each one down on a scratch pad so I could keep track. It seems that most of this complexity was a result of OpenJUMP's ability to select parts of Features, and not being restricted to selection of whole features. I wonder if we couldn't come up with a much simpler selection system that only selected whole features. We could probably do this using a single collection that stored only the FID of a Feature, or an object reference to the Feature. A collection of a couple million FID values would only be a couple of MB correct? Perhaps your idea with the fence is best, but I'm thinking it might be better to address the complexity in the selection system itself. I wonder how much people are using OpenJUMP's ability to select "parts" of features. Just my thoughts. I don't think it would take me long to cook up the simple "whole-feature-selection-only" system I am talking about. The Sunburned Surveyor On 10/8/07, Stefan Steiniger <[EMAIL PROTECTED]> wrote: > simple solution and well thought :) > > we should go for > > stefan > > Larry Becker wrote: > > > Hi, > > > > Recent work with Extract Layers by Geometry Type, and improving > > OpenJump's support for very large selections, has convinced me that > > JUMP needs a mechanism for dealing with subsets of large layers. > > Although the selection mechanism is very flexible, it is very > > expensive in terms of memory and processing. To seem what I mean, > > consider Arnd's million point layer problem. To break the layer into > > more manageable pieces, he tried to select some of the points and move > > them to another layer. When this is done with such a large selection, > > the UI must build gigantic data structures. The result is an > > extremely slow response or an out of memory error. > > > > An approach that might work for some problems is to use the Fence tool > > to indicate a subset of the data that can be used in place of a > > selection. The advantage is that no data structures are needed and > > there are no selection handles to draw. I was thinking of producing > > another Layer Extract plugin that would extract features in the Fence > > to a new layer. By coding support methods in a utility class, we > > could gradually add support for "features in fence" subsets to the > > other tools. > > > > What do you think? > > > > regards, > > > > Larry Becker > > > > -- > > http://amusingprogrammer.blogspot.com/ > > > >------------------------------------------------------------------------ > > > >------------------------------------------------------------------------- > >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 > ------------------------------------------------------------------------- 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
