Jody Garnett ha scritto: > 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 like the wrapper better, me too. ... >> 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 Done. >> >> 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. Ok, good. > I also considered a page from Justin's book: > interface FeatureVisitor { > boolean visit( Feature f, Object extraData ); > } > Not sure what I think of that.... I don't really know what book you're referring to. And what the extra data could be, either :) > 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. And how do I bail out of the entire process then? By returning false repeatedly...hmm... ok, may not be super nice, but probably good enough. >> 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. Sigh. Can we have this layered in two classes then, FeatureCollection and FeatureAssociation, where FeatureAssociation is a collection and is a Feature at the same time? And then have the datastores return the latter only when it makes sense to? I really really don't want the extra complexity of SimpleFeature around if it's not strictly necessary. I definitely don't see myself implementing a FeatureCollection like the one you want, and I doubt Justin would want to (feel free to prove me wrong anyways). >> 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? Yeah, I guess it is, we just have to bridge it somehow to a Map so that it can be renderer. Another DataUtilities method or something I guess... Cheers Andrea ------------------------------------------------------------------------- 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
