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 an implementation you can cut and paste in:
/**
* Accepts a visitor, which then visits each feature in the collection.
* @throws IOException
*/
public void accepts(FeatureVisitor visitor, ProgressListener progress ) throws
IOException {
Iterator<SimpleFeature> iterator = null;
if( progress == null ) progress = new NullProgressListener();
try{
float size = size();
float position = 0;
progress.started();
for( iterator = iterator(); !progress.isCanceled() && iterator.hasNext();){
if (size > 0) progress.progress( position++/size );
try {
SimpleFeature feature = iterator.next();
visitor.visit(feature);
}
catch( Exception erp ){
progress.exceptionOccurred( erp );
}
}
}
finally {
progress.complete();
close( iterator );
}
}
(I moved this discussion to just geotools-devel)
Is there any other part of FeatureCollection you are unable to implement? We do
not expect FeatureCollection to extend java.util.Collection; and I am
interested in learning what you are having difficulty with.
Letting half implemented feature collections run around the library is a good
way to cause frustration for people trying to use stuff.
--
Jody Garnett
Sent with Sparrow
On Monday, 24 January 2011 at 3:10 PM, Niels wrote:
> 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 FeatureCollection from the general Collection interface in java,
> as it implements all the same methods. Because a Feature Collection is not a
> Collection, I am making a Collection wrapper for a FeatureCollection, and
> also wondering if that maybe already exists somewhere? Seems like an obvious
> thing.
>
> On 24/01/11 12:50, Jody Garnett wrote:
> > That is fine; have a look at one of the other implementations of accepts -
> > you can make an implementation that is based around your iterator(). It
> > ends up being a for loop that calls the visitor each time through the loop;
> > on each feature in turn.
> >
> >
> > Jody
> >
> > --
> > Jody Garnett
> > Sent with Sparrow
> > On Monday, 24 January 2011 at 12:58 PM, Niels wrote:
> >
> > > On 22/01/11 07:39, Jody Garnett wrote:
> > > > On 21/01/2011, at 5:01 PM, Niels wrote:
> > > >
> > > > > I succeeded in getting wms:getFeatureInfo produce GML3 output from
> > > > > complex features (Yay!). However, I am now working on using HTML
> > > > > templates with getFeatureInfo. I noticed in the code that processes
> > > > > templates, that it loads all features in memory first. However, it
> > > > > uses operations in the FeatureCollection that are not supported by
> > > > > MappingFeatureCollection in app-schema.
> > > > >
> > > > >
> > > > >
> > > > What operations in FeatureCollection are not supported by
> > > > MappingFeatureCollection? Perhaps you want to take this to the geotools
> > > > list if it is a problem to be worked out? But yeah; there should be no
> > > > call to load everything at once; but even if the code does do that - it
> > > > should not effect your implementation of FetaureCollection. Jody
> > > >
> > > >
> > > >
> > > There is a whole series of methods not supported in
> > > MappingFeatureCollection: anything that modifies the list (add, clear,
> > > etc.) but the one used in the template code is "accepts" to support
> > > visitors that visit all features. I think the reason is that a
> > > MappingFeatureCollection doesn't actually hold any features, the features
> > > are only created when you use the iterator.
> > >
> > > I don't know if this should or can be worked out, because loading a
> > > whole collection of complex features in memory just doesn't sound like a
> > > good idea...
> > >
> > > --
> > > Niels Charlier
> > >
> > > Software Engineer
> > > CSIRO Earth Science and Resource Engineering
> > > Phone: +61 8 6436 8914
> > >
> > > Australian Resources Research Centre
> > > 26 Dick Perry Avenue, Kensington WA 6151
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >
> >
>
>
> --
> Niels Charlier
>
> Software Engineer
> CSIRO Earth Science and Resource Engineering
> Phone: +61 8 6436 8914
>
> Australian Resources Research Centre
> 26 Dick Perry Avenue, Kensington WA 6151
>
>
>
>
------------------------------------------------------------------------------
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires
February 28th, so secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsight-sfd2d
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
