Larry, Thanks for the comments. I agree it is always hard to "rip out" functionality that has been supported for a long time. I only thought it might be better to spend the time fixing the real problem than coming up with an alternative selection mechanism.
However, you may indeed be correct. Making the necessary changes might just be too difficult. One thing I have learned to dislike about OpenJUMP: A plug-in developer has access to all of the internal methods that have public access. It seems like a system where extension points are well defined would make refactoring easier. (I think Eclipse uses this type of system.) I guess this gets back to the flexibility versus complexity debate. :] I can't think of a way to more efficiently support "part selection" off the top of my head. I think my idea would have only worked for "whole feature selection". Thanks for taking the time to discuss this with me. I always learn a lot from our conversations. The Sunburned Surveyor On 10/8/07, Larry Becker <[EMAIL PROTECTED]> wrote: > Hi SS, > > I agree that the problem with selection is the large collections being > generated. "Parts" are only part of the problem and it is a bit late to > stop supporting this capability. Optimizations are always possible, but > only if you have a clear understanding of what you are optimizing and use > benchmarks for metrics. > > Larry > > > On 10/8/07, Sunburned Surveyor <[EMAIL PROTECTED]> wrote: > > 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 > > > > > > -- > 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
