Jody Garnett wrote: > 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 think you have communicated your intention just fine... its just that from my point of view while this seems like a very noble and lofty goal i dont think its very practical. Anyways... my two cents. > > 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) Lets not even mention ISO19107... we should really be refusing to allow specs like this one to influence what our classes look like when there is absbolutley *no* mandate to do so. Just because some spec that nooone without years of modelling experience can understand says so.
If someone really wants an ISO19107 FeatureCollection and wants to pay for it then giddy up. Lets give them a module and all that jazz and let them play. If not I suggest we focus on the minimum of what is useful for geotools and easy to maintain. Unfortunately I have come to this point of reasoning after we decided to go with the geoapi feature model... > > 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 > > !DSPAM:4007,46af637d220781804284693! > -- 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 Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
