Well one evil thing to do would be to scan through once and collect
the feature ids (perhaps you could do that efficiently?); and then
make a collection that produces an iterator that fetches the matching
feature for each feature id in turn?
Not the best idea; but something.
The problem wi
Well one evil thing to do would be to scan through once and collect the feature
ids (perhaps you could do that efficiently?); and then make a collection that
produces an iterator that fetches the matching feature for each feature id in
turn?
Not the best idea; but something.
--
Jody Garnett
On 24/01/11 16:53, Jody Garnett wrote:
Understood; thanks for the clarification. If you can kindly implement
accepts for other code it would be keen.
Sure, no problem.
Nice idea with the wrapper; although leaving open the danger of not
closing the iterator?
Hmmm, that's a good point, hadn
Jody,
You misunderstand, too :P
I know you don't need to load all the features into memory for "accepts"
to work.
But in the template implementation, "accepts" is *used* to go through
all the features and load them all at once in a list.
In principle, I have nothing against implementing accepts
You miss understand; you do not need to load all the features into memory for
"Accepts" to work. It is really intended to be an easier for loop for people to
code against (indeed they are thinking of making this style of programming part
of Java 7 - and calling it an "inner" iterator).
Here is
Yeah I guess that would be easy to do, but as i said, I don't think we
/want/ all features to be loaded in memory at once.
I was looking at a different option, but need to threat a
FeatureCollection as a Collection for that. I was wondering why it was
chosen not to derive the interface of Featur
