Andrea Aime wrote: >> 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). I think this is the entire source of our conflict; unless I can communicate the need (or intention) here - FeatureCollection it is always viewed as overhead rather than the point of the exercise.
I have added the following to my list of things I will give up: - Use of FeatureCollection as the result of feaureSource.getFeatures() (if we really cannot handle the overhead of implementing Feature then lets not pretend we are producing a FeatureCollection in the ISO19107 sense) Really if we are not implementing FeatureCollection then we are wasting our time; we can make an API for data access but we need to understand (and communicate) that this is all we are doing. We can leave FeatureCollection well enough alone. 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 [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
