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. Regardless of which way we do it how does the user become aware that problems occurred? I mean when you render a dataset for instance and there are problems with some features you might want to render the rest but still give the user information about which features failed.
ProgressMonitor could be one way... so I guess that is a +1 for visitor. I guess for iteration the wrapper approach could be used and the wrapper could save those exceptions that occur and possibly the fids of features that fail? Not sure... > > 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. 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. If we change interfaces again i dont think this can fly. Like Andrea says there is so much code that now uses FeatureCollection that we are going to need to try and bend our client code around teh new interface. Primarily this means leaving it named "FeatureCollection". > > 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. > Again its a compatability thing... not having an iterator means all of our client code breaks... i think having both is the compromise.... and perhaps some javadocs saying that using visitor is "safer" or whatever. > > > 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(); > } > > 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(); > } > } > > 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. > > 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. > 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). > > 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? I can see both points... and when it comes down to it I think having FeatureCollection be a feature with bounds available as an attribute is just confusing to users... But... as long as there is only one hard interface to implement i am cool with whatever. Since noone actually calls feature methods on featurecollection i dont really care if we just stub them all to return null. Just as long as we have a sane class hierachy for implementors a base class which *all* feature collections use and one that implmeents the methods on Feature. And get rid of the current 3 abstract feature collection classes all of which implemnet feature and collection differently. As an implementor i do not want to even look at the feature interface. I only want to implement the code for an iterator for the collection. that is it. > > > > 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. what about geoapi? Are we going to apply these changes to FeatureCollection in geoapi.... i guess we kind of have to ... > > 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). > > Cheers > Andrea > > > !DSPAM:4007,46aef64f108702092453641! > -- Justin Deoliveira The Open Planning Project http://topp.openplans.org ------------------------------------------------------------------------- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
