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
