Andrea Aime wrote:
> Hi,
> some quick comments on the two pages making up
> the Collection proposal.
>
> http://docs.codehaus.org/display/GEOTOOLS/FeatureCollection+Clean+up+Motivation
>
>
>
> About the "working with invalid data", we have to deal with it both
> iteration and visiting wise. So, it seems to me we should handle this
> at the feature collection level and have a "skip invalid features"
> property. FeatureCollection.setLenient/isLenient could be a way.
Justin was of the viewpoint we should give users a wrapper to use, one
that could do an "isValid" check on the Features. I don't mind as long
as the default is to produce warnings rather than fail.
> I don't agree on splitting FeatureResults and FeatureCollection again,
> I would prefer to see FeatureColletion altered so that the most
> used methods stay there, we can try the morphing against our code
> and see how much it breaks.
Hi Andrea; that page lists several ideas that were presented,
Re-introducing FeatureResults was rejected - but I thought I should
write the
idea down so I could mention why. There is not enough difference
between FeatureResults and FeatureSource, the DataStore.getView method
that returns a FeatureSource covers the same ground that the
FeatureResults idea did.
> For example, keep the iterator() method,
> but have it return a FeatureIterator instead. Most code will stay
> there unchanged, but even code completion wise you would notice you're
> not getting back a plain Iterator.
Agreed, I think it may even be this way on trunk right now; the moment
we stop supporting Collection<Feature> most of the Java 5
syntatic sugar will get out of our way.
> Iterator vs Visitor, I think we should keep them both because Visitor
> is a little alien to the average java programmer, especially when
> applied to something as simple as a collection, which is perceived as
> a sort of list, when visitor is usually applied to complex data
> structures that can be visited in a variety of ways.
> I'd say keep them both, and let the code examples speak by themselves
> on which one is easier and less error prone to use.
Agreed, please feel free to funnel your feedback onto that page.
> http://docs.codehaus.org/display/GEOTOOLS/FeatureCollection+clean+up
>
> About visitor returning a boolean, it looks ok, maybe it could be
> even simpler... or maybe I'm just being overzealous. What about
> having a FeatureVisitor interface like:
>
> interface FeatureVisitor {
> void visit(Feature f);
> boolean keepVisiting();
> }
By that token you could always cancel your opperation with the
ProgressListener as well. The reason I would like to keep things
to a single method is so we can take advantage of "closure" stuff in the
future.
I also considered a page from Justin's book:
interface FeatureVisitor {
boolean visit( Feature f, Object extraData );
}
Not sure what I think of that....
> and then have the abstract visitor have a field that you can set
> calling "breakVisit()" within the visit method, that is:
>
> void visit(Feauture f) {
> if(f.getId().equals(theIdLookedFor) {
> feautureLookedFor = f;
> breakVisit();
> }
> }
Right. 6 of one 1/2 dozen of the other.
The last thing to consider is if we can allow for visiting
"SimpleFeature" in a smooth manner.
> The code is simpler if you don't need have "bail out in the middle"
> behaviour. I don't know, just a random idea. I'm very much ok with
> returning a boolean too.
Returning a boolean is common, but it does introduce an extra line for
implementors - right where they hate it (in an anonymous class).
The last think is to think about visiting more complicated structures
like a GML document, where the visitor may be execpted to visit several
kinds of content - including "nested" FetaureCollection, I submit to you
that the boolean returned would only back you out of the current
FeatureCollection - not the entire visitor process.
> About FeatureCollection being a Feature, I still don't get it.
> Accessing bounds as an attribute seems silly to me, and if we need
> extra metadata to keep up we can add them.
I am not sure how to communicate much more on this front Andrea. The
best we could do is go through one of Gabriels GML documents?
> Most of the methods in SimpleFeature just don't apply:
> http://geoapi.sourceforge.net/pending/javadoc/org/opengis/feature/simple/SimpleFeature.html
>
>
> (and neither are the many methods I see in the superinterfaces).
I think this is a case where we both are stuck; I do not see how these
do not apply? I cannot imagine (or use) FeatureCollection without them.
Yeah sure I could use it just to access the contents - but I am not
interested in that. I could use a straight FeatureReader if that was all
I was interested in.
> If someone really need to see the colleciton as a Feature, can't we have
> a FeatureCollection.asFeature() : Feature method that adapts it (maybe
> optionally implemented, so that if a collection is a mere data container
> it could just return null?
Nope. Flip it the other way around; have your FeatureSource return
several things if your want (FeatureReader, Collection<Feature>,
whatever ...), but having FeatureCollection as a distinct idea is
something we gotta have.
> As a final note, I'd say we should try to come up with a full
> FeatureCollection specification, and then submit it somehow to the
> users too for feedback.
Indeed, from my stand point I want to round up the ideas you have had
(and others too) and make sure they do not get lots.
> Also, since we're hitting this, we should try to include in this work
> a way to have the feature collection stored in memory, but still be
> usable as an input to a map, so that people can happily keep all of
> their features into memory, if that's what they want (but maybe we just
> have to fix the CachingFeatureSource I wrote some time ago for a user).
Reminds me I need to add "events" as something I am willing to give up
(although Jesse will kill me). I put in a method for
featureCollection.collection() - is that suitable?
Cheers,
Jody
-------------------------------------------------------------------------
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/
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
